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EXECUTIVE  SUMMARY 


Increasingly,  construction  industry  private  and  public  organizations  are  placing  greater 
emphasis  and  value  on  data,  information,  and  knowledge1 . Virtually  every  organization 
is  an  information  provider  and/or  information  consumer.  For  many  private  organizations, 
advertising,  access  to  construction  information  and  customer  service  is  key  to 
maintaining  a competitive  advantage.  For  government  and  academia,  publishing  and 
sharing  research  results  electronically  results  in  a significant  advantage  over  previous 
methods  such  as  printed  materials.  Though  information  technology  has  provided  benefits 
in  faster  delivery  and  vast  storage  capabilities,  it  has  not  delivered  significant 
improvements  in  searching,  interconnecting,  and  interpreting  information.  This  is  largely 
due  to  the  lack  of  consistency  in  representing  and  defining  construction  industry 
knowledge,  the  distributed  nature  of  the  knowledge,  the  contextual  nature  of  knowledge 
that  is  very  context  dependent  and  the  lack  of  resources  to  focus  on  these  issues.  The 
industry  needs  a non-biased  organization  that  both  produces  knowledge  and  has  the 
capabilities  to  develop  and  test  methodologies  and  a unified  framework.  This  effort  must 
be  performed  in  unison  with  construction  industry  associations  and  institutes,  private 
companies,  academia,  and  other  government  organizations.  The  National  Institute  of 
Standards  and  Technology  (NIST)  has  been  focusing  on  important  knowledge  issues  that 
affect  the  representation,  exchange,  and  understanding  of  construction  industry  materials, 
products,  and  systems  through  its  Computer-Integrated  Knowledge  System  Network 
(CIKS)  program.  Collaborative  efforts  with  organizations  such  as  the  American  Concrete 
Institute  (ACI),  The  Society  for  Protective  Coatings  (SSPC),  and  the  American  Society 
for  Testing  and  Materials  (ASTM)  have  resulted  in  the  development  of  methods  to  aid 
knowledge  representation  and  exchange. 

In  1 996,  the  first  CIKS  workshop  was  held  in  Gaithersburg,  Maryland.  This  workshop 
attempted  to  define  the  focus  and  goals  of  the  CIKS  program.  Keynote  presentations 
describing  construction  industry  applications  were  given.  Representatives  from  industry, 
government  and  academia  met  in  construction  materials  and  information  technology 
working  groups  to  develop  agendas  for  further  work,  recommendations  on  collaborative 
efforts  and  funding  and  knowledge  user  needs.  A NIST  report  titled  “A  Partnership  for  a 
National  Computer-Integrated  Knowledge  Systems  Network  for  High-Performance 
Construction  Materials  and  Systems:  Workshop  Report”  describing  the  agenda  and 
results  was  published  in  March  of  1 997  [1].  As  a result  of  the  workshop,  two  CIKS 
active  working  groups  emerged.  These  working  groups  representing  the  concrete  and 
industrial  coatings  materials  areas,  began  by  focusing  on  three  principal  areas: 


1 For  the  purposes  of  this  report,  data  is  represented  by  individual  observations  such  as  research  results, 
information  is  organized  data  such  as  tables  and  directories,  knowledge  is  represented  as  engineering 
guides  and  accepted  practice  such  as  rules  developed  by  higher-level  knowledge  staff,  such  as  materials 
experts.  The  term  knowledge  will  be  used  in  this  report  as  a general  term  that  may  also  include  data  and 
information  except  as  specifically  stated. 
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1 . Investigation,  testing,  and  adoption  of  relevant  information  technologies  and 
knowledge  issues  facing  the  construction  industry  materials  area. 

2.  The  development  of  consistent  methods,  such  as  formats  and  terminology  for 
aiding  in  the  representation  and  exchange  of  knowledge. 

3.  Further  development  of  decision  support  applications  to  aid  in  the  use  and 
understanding  of  construction  industry  knowledge. 

The  groups,  working  independently  and  with  technical  associations  and  institutes  have 
jointly  produced  several  industry  standards  and  applications  that  address  specific  sponsor 
needs  for  knowledge  representation  and  exchange  and  decision  making  and  will  also 
benefit  construction  industry  organizations  as  a whole.  These  efforts  include;  guides  and 
standards  for  the  identification  and  representation  of  concrete  constituent  material 
properties,  a guide  for  the  representation  and  exchange  of  industrial  coating  product  data, 
engineering  decision  support  systems  for  bridge  coating  and  concrete  hydraulic 
structures,  and  methods  for  promoting  the  exchange  of  construction  industry  knowledge. 
These  results  are  described  in  detail  later  in  this  report.  In  addition,  the  NIST  CIKS  staff 
produced  a report  on  a proposed  CIKS  framework  that  was  published  in  September  1 997 
[2]- 

During  the  process  of  investigating  information  technologies  and  user  needs  for  CIKS,  it 
became  obvious  that  several  critical  factors  hindered  its  success  and  for  the  program  to 
provide  significant  gains,  these  factors  must  be  addressed.  These  factors  included: 

□ Existing  knowledge  bases  are  distributed  and  fragmented  and  costs  for  redesign  are 
too  great. 

□ The  construction  materials  industry  lacked  consistent  terminology  and  formats  for 
representing  electronic  data. 

□ The  construction  materials  industry  lacked  universal  activity  and  process  models  for 
building  unified  or  interoperable  knowledge  bases. 

□ The  construction  materials  industry  lacked  criteria  for  evaluating  knowledge. 


Based  on  these  factors  and  the  need  to  advance  the  CIKS  program,  a 2nd  CIKS  workshop 
was  held.  The  goals  of  this  workshop  were  to  focus  on  the  critical  factors  stated  above  by 
bringing  together  organizations  having  active  programs  and  projects  that  could  provide 
synergy.  This  workshop  was  held  in  September  1 997  and  is  the  focus  of  this  report. 
During  the  2nd  workshop,  keynote  presentations  focused  on  the  critical  elements  for 
knowledge  interoperability  and  several  working  groups  met  to  discuss  their  progress  and 
to  plan  further  work. 
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Today,  the  concrete  and  industrial  coatings  working  groups  remain  active  within 
committees  of  the  American  Concrete  Institute  and  the  Society  for  Protective  Coatings, 
respectively.  Also,  NIST  continues  to  pursue  the  CIKS  goals  in  a more  focused 
direction,  namely,  the  Partnership  for  High-Performance  Concrete  Technology  Program. 
Technical  societies  have  adopted  CIKS  methodologies  for  knowledge  sharing  and 
organizations  such  as  the  Federal  Highway  Administration,  Tumer-Fairbanks  Research 
Center  and  the  U.S.  Army  Corps  of  Engineers  are  actively  developing  engineering 
decision-support  systems  for  their  structures. 

The  realization  of  CIKS  has  enormous  potential  for  the  construction  industry.  It  will 
require  increased  collaboration  between  NIST,  the  private  sector  and  other  government 
organizations.  NIST  maintains  a neutral  position  and  can  play  an  important  role  by 
assisting  societies  and  institutes  that  need  to  address  the  needs  of  their  constituents. 
Undoubtedly,  further  meetings  and  workshops  will  be  necessary  in  order  to  present 
knowledge  producers  and  consumers  with  innovative  techniques  and  to  ensure  a 
synergistic  approach.  There  remains  a need  to  influence  information  technologists  in  the 
development  of  appropriate  technologies  that  address  the  needs  of  scientific  and  technical 
information. 

Finally,  construction  industry  feedback  on  CIKS  is  vital  and  comments  are  welcome. 

This  report  is  being  made  available  in  printed  form  as  a National  Institute  of  Standards 
and  Technology  Internal  Report  and  is  available  on  the  CIKS  website  at  the  address: 
www.ciks.nist.gov. 

The  recommendations  from  the  workshop  were: 

□ A strawman  should  be  developed  based  on  the  coatings  and  concrete  working  group 
activities.  This  strawman  should  have  priority  in  the  next  phase  in  the  CIKS 
development  and  should  be  presented  at  a future  CIKS  workshop. 

□ A future  CIKS  workshop  should  include  greater  representation  from  the  construction 
industry  user  community. 

□ Working  groups  should  continue  to  meet  at  6 month  intervals  in  order  to  maintain 
progress  in  their  respective  areas. 

□ The  report  from  the  workshop  should  be  distributed  to  attendees  and  construction 
industry  organizations  interested  in  knowledge  base  activities. 

□ Industry  should  express  its  support  to  NIST  for  CIKS 
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ABSTRACT 


The  2nd  workshop  on  a National  Partnership  on  Computer-Integrated  Knowledge 
Systems  (CIKS)  Network  for  High-Performance  Construction  Materials  and  Systems 
(NPCMS)  was  held  in  Gaithersburg,  MD  on  September  24th  and  25th,  1997.  The 
workshop  was  sponsored  by  the  Building  and  Fire  Research  Laboratory  of  the  National 
Institute  of  Standards  and  Technology,  the  Construction  Materials  Council  of  the  Civil 
Engineering  Research  Foundation,  and  the  American  Society  for  Testing  and  Materials. 
The  workshop  mission  was  to: 

Provide  a forum  for  developing  and  participating  in  an  industry-wide  effort  to 

address  the  information  needs  of  private  and  public  organizations  within  the 

construction  industry. 

The  workshop  objectives  were  to: 

□ Identify  and  prioritize  current  and  future  information  needs  of  the  construction 
industry  as  they  relate  to  construction  materials  and  systems. 

□ Critique  the  proposed  framework  for  developing  and  implementing  CIKS. 

□ Identify  and  assess  opportunities  for  private  and  public  partnerships  for 
developing  CIKS. 

In  the  pursuit  of  these  objectives,  experts  representing  private  and  public 
construction  industry  organizations  and  information  technologists  presented  information 
on  projects  that  comprised  a major  information  representation  and  distribution 
component.  Also,  representatives  from  facility  owners,  technical  associations  and 
societies,  consultants  and  engineers,  and  universities  met  in  working  groups  to  identify 
knowledge  user  needs  and  to  critique  the  relevance  of  keynote  presentations  to  their 
project  and  organizations  goals.  Two  working  groups;  1)  concrete  and  2)  coatings 
developed  substantial  agendas  and  recommendations  for  pursuing  the  CIKS  mission  and 
objectives.  The  consensus  of  the  group  revealed  that  CIKS  could  significantly  improve 
the  distribution  and  use  of  electronically  stored  knowledge  and  that  the  concrete  and 
coatings  working  groups  should  be  a model  for  other  working  groups  to  pursue.  This 
report  presents  information  contained  in  the  keynote  addresses  and  results  of  the  working 
group  sessions. 


Keywords:  computer  integrated  knowledge  system;  construction  industry;  high- 
performance  construction  materials;  information  technology,  knowledge  interoperability, 
knowledge-based  systems;  workshop. 


DISCLAIMER 


The  reference  to  commercial  equipment,  instruments,  computer  hardware  and 
software  in  this  report  are  identified  in  order  to  provide  examples  of  experimental 
procedures  and  methodologies.  Such  identification  is  not  intended  to  imply 
recommendation  or  endorsement  by  the  National  Institute  of  Standards  and  Technology, 
nor  is  it  intended  to  imply  that  the  materials  or  equipment  identified  are  necessarily  the 
best  available  for  the  purpose. 
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1.  INTRODUCTION 


The  2nd  workshop  on  the  Computer-Integrated  Knowledge  Systems  (CIKS)  Network 
for  Materials  and  Systems  was  held  on  September  24-25,  1997  at  the  Holiday  Inn  in 
Gaithersburg,  Maryland.  The  workshop  was  sponsored  by  the  National  Institute  of 
Standards  and  Technology  (NIST),  the  Civil  Engineering  Research  Foundation  (CERF), 
Construction  Materials  Council  (CONMAT  Council)  and  the  American  Society  for 
Testing  and  Materials  (ASTM).  The  purpose  of  this  workshop  was  to  advance  the  CIKS 
program  by  seeking  new  input  on  knowledge  needs  from  construction  industry 
organizations,  discuss  and  document  progress  occurring  in  the  CIKS  Working  Groups, 
and  critique  the  proposed  CIKS  framework.  Unlike  the  1st  CIKS  workshop,  the  2nd 
workshop  had  a more  narrow  focus.  Although  the  agenda  provided  for  the  opportunity 
for  all  construction  industry  organizations  to  attend,  based  on  the  participation  and 
subject  areas  programmed  for  the  keynote  talks,  the  following  topics  and  assumptions 
became  the  workshop  focus. 

□ Construction  materials,  products,  and  systems 

□ Engineering-related  activities  such  as  diagnostics,  material/product  selection,  and 
repair  procedures  and  materials 

□ Public  works  structures  (e.g.,  highway  bridges  and  pavements,  and  hydraulic 
structures  such  as  locks  and  dams) 

□ Electronic  knowledge  representation  for  terminology  and  nomenclature,  databases, 
computer-based  models,  and  decision  support  modules 

□ Knowledge  interoperability  (the  capability  of  accessing  and  integrating  knowledge 
among  computer  based  knowledge  systems  in  a seamless  manner). 


1.1  Purpose  and  Goals  of  the  CIKS  Network 

The  initial  goals  for  CIKS  were  defined  by  NIST  during  the  1 st  workshop.  They 

included  provisions  for: 

□ Universal  electronic  access  to  distributed  material  data,  information,  and  knowledge; 

□ Application  systems  that  use  the  data,  information,  and  knowledge  in:  (a)  material 
design,  and  (b)  facility  design,  construction  or  installation/application,  operation, 
maintenance,  repair  and  disposal; 

□ An  open  testbed  for  industry,  university,  and  government  partners  to  build  and 
evaluate  prototype  systems,  including  enabling  information  technologies; 

□ Commercial-scale  systems  developed,  deployed  and  maintained  by  industry. 
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These  goals  represented  an  ambitious  undertaking  and  long-term  vision  for  the 
program.  They  would  require  vast  amounts  of  staff  and  funding  resources  and 
collaboration  by  construction  industry  organizations.  Results  of  the  first  workshop  and 
collaboration  from  1996-1997  indicated  that  in  order  for  CIKS  to  make  progress  in  its 
goals,  a more  focused  agenda  would  have  to  be  adopted.  Therefore,  the  topics  and  focus 
areas  described  in  the  Introduction  became  the  primary  agenda  for  CIKS  activities.  In 
addition,  attempts  were  made  to  create  partnerships  with  organizations  whose  goals  and 
agendas  complimented  the  refined  CIKS  program.  As  a result  several  partnerships  were 
created  that  involved  NIST  and  the  following  construction  industry  and  academic 
organizations.  These  included: 

□ The  American  Concrete  Institute 

□ The  Society  for  Protective  Coatings 

□ U.S.  Department  of  Transportation,  Tumer-Fairbanks  Research  Center 

□ U.S.  Army  Corps  of  Engineers,  Waterways  Experiment  Station 

□ University  of  Maryland  Baltimore  County 

These  organizations  are  represented  by  many  different  disciplines  and  include  standards 
committees,  facility  owners,  consultants,  contractors,  engineers,  researchers,  and 
information  technologists.  These  partnerships  exist  today  and  specific  projects  are 
underway  to  address  construction  industry  knowledge  needs.  Details  of  the  projects  are 
presented  in  the  CIKS  Working  Group  summaries,  later  in  this  report. 

1.2  Status  of  CIKS  and  The  Testbed 

Since  its  beginning,  the  CIKS  program  has  strived  to  develop  a meaningful  focus  that 
is  practical  and  useful  from  two  perspectives;  1)  to  demonstrate  prototype  systems  and 
methodologies  that  can  be  adopted  by  construction  industry  organizations  in  their 
development  of  knowledge  bases,  and  2)  to  disseminate  NIST  research  results  related  to 
high-performance  construction  materials  and  systems  (HPCMS).  Since  the  construction 
industry  is  represented  by  small  and  medium  sized  companies,  it  was  important  to  partner 
with  organizations  that  maintain  leadership  positions  and  who  must  deal  with  many 
constructed  facilities  and  complex  problems.  This  strategy  is  evident  in  the  type  of 
organizations  listed  in  the  partnerships  identified  in  the  previous  section.  The  following 
activities  are  examples  of  the  interactions: 

□ Joint  CIKS  Working  Groups  with  the  American  Concrete  Institute  and  the  Society  for 
Protective  Coatings  knowledge  committees. 

□ Adoption  of  NIST-developed  methodologies  for  engineering  decision  support 
applications  for  highway  and  hydraulic  structures  within  the  Federal  Highway 
Administration,  Tumer-Fairbank  Research  Center  and  hydraulic  structures  with  the 
U.S.  Army  Corps  of  Engineers,  Waterways  Experiment  station. 
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□ Adoption  of  methodologies  for  intragroup  communication  within  the  industrial 
coating  industry. 

□ Adoption  of  Internet  remote  access  methods  for  construction  material  property  and 
product  databases  involving  coating  and  concrete  constituent  materials. 

Specific  details  and  references  for  these  projects  are  described  in  the  CIKS  Working 
Group  summary  reports.  In  addition,  examples  not  originally  represented  in  the  CIKS 
focus  are  the  NIST  Coatings  Service-Life  Prediction  Consortium  [3]  and  the  Partnership 
for  Advancing  Technology  for  Housing:  Durability  (PATH-D).  These  programs  are 
already  using  many  of  the  CIKS  methodologies  or  are  giving  them  consideration.  The 
CIKS  Internet  database  server  and  World  Wide  Web  site  [http://www.ciks.nist.gov]  have 
been  instrumental  in  disseminating  information  regarding  the  CIKS  program. 

1.3  Workshop  Objectives 

The  objectives  of  the  2nd  CIKS  workshop  were  established  so  that  information  on 
several  important  topics  and  features  of  CIKS  could  be  presented  and  discussed.  The 
workshop  was  intended  to  foster  discussion  of  specific  on-going  projects,  forge  new 
partnerships,  and  critique  the  proposed  CIKS  framework.  The  stated  objectives  were: 

□ To  identify  and  prioritize  current  and  future  knowledge  needs  of  the  construction 
industry  as  they  relate  to  construction  materials,  products,  and  systems. 

□ To  critique  the  proposed  framework  for  developing  and  implementing  CIKS. 

□ To  identify  and  assess  opportunities  for  private  and  public  partnerships  for 
developing  CIKS. 

These  objectives  were  then  considered  based  on  the  interest  expressed  by  the  participants 
and  in  the  context  of  the  workshop  focus  areas  identified  in  the  Introduction  to  this  report. 

In  an  attempt  to  keep  the  workshop  focused,  an  underlying  premise  and 
architecture  was  developed  by  NIST  before  the  meeting.  Since  the  ultimate  goal  for 
CIKS  is  to  provide  universal  access  to  electronically  stored  and  evaluated  knowledge, 
critical  elements  were  identified.  These  included  terminology  and  nomenclature, 
standardized  knowledge  formats,  and  process  and  activity  models.  Addressing  these 
areas  would  maximize  the  potential  for  seamless  knowledge  integration  (interoperability) 
among  electronically  distributed  knowledge  bases.  Figure  1 identifies  the  critical 
elements  and  shows  the  connections  and  examples  of  construction  industry  activities. 
Using  this  as  a model,  along  with  the  use  of  commercial  off-the-shelf  information 
technologies,  applications  could  then  be  developed  and  knowledge  use  improved. 
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Figure  1:  CIKS  critical  elements  and  construction  industry  activities. 


1.4  Workshop  Organization 

The  organizational  structure  of  the  workshop  is  presented  in  Appendix  A of  this 
report.  The  Appendices  also  contain  information  and  lists  of  sponsoring  organizations, 
committees,  participants  and  working  groups.  The  program  for  the  workshop  began  on 
day  1 with  a welcome  and  introduction  by  the  CIKS  Coordinator.  To  set  the  stage  for 
presentations  and  discussions  and  to  demonstrate  the  need  for  a unified  effort  for 
knowledge  activities  within  the  construction  industry,  Dr.  Richard  Wright,  Director  of  the 
NIST,  Building  and  Fire  Research  Laboratory  gave  a presentation  on  “Sound  Decisions 
in  Design,  Construction  and  Use  of  Constructed  Facilities.” 

Seven  keynote  presentations  followed  during  the  morning  session.  The  keynote 
presentations  were  divided  into  two  groups.  Keynote  I,  “Building  Blocks  for  Knowledge 
Exchange,”  presented  information  on  terminology,  tools  for  knowledge  sharing, 
electronic  commerce  for  engineering  application.  Presentations  in  the  Keynote  II  group 
were  given  by  representatives  from  industry  who  discussed  and  demonstrated  actual 
applications.  The  final  keynote  presentation  was  given  on  the  CIKS  Framework  and 
Testbed  by  Thomas  Kurihara  of  the  CIKS  staff. 

At  the  completion  of  the  keynote  presentations,  John  Meyer,  Workshop  Co-chair, 
presented  a charge  to  the  working  groups.  The  goals  and  objectives  for  the  CIKS 
Working  Group  breakout  sessions  were: 
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□ Identify  knowledge  user  needs  for  materials,  components,  and  systems. 

□ Critique  the  proposed  CIKS  framework  for  its  application/benefit  to  materials  areas. 

□ Identify  opportunities  for  partnerships  and  funding  sources. 

□ Develop  and  prioritize  recommendations  on  pilot  projects  and  the  NIST  role. 

The  working  groups  met  during  the  afternoon  of  Day  1 and  the  morning  of  Day  2 to 
address  their  agenda.  Groups  meeting  during  the  breakout  sessions  included 

□ Aluminum  (WG1) 

□ Coating  (WG2) 

□ Composites  and  Geosynthetics  (WG3) 

□ Concrete  and  Masonry  (WG4) 

□ Fire  Safety  (WG5) 

□ Information  Technology  (WG6) 

Information  technologists  were  assigned  to  each  CIKS  Working  Group.  They  served  as  a 
resource  to  assist  the  working  group  members  in  addressing  their  goals  and  objectives 
and  to  explain  information  technology  issues.  The  Information  Technology  Working 
Group  also  met  on  Day  2 to  discuss  their  interactions  and  to  critique  the  materials 
working  group  breakout  sessions.  Upon  completion  of  the  working  group  sessions  on  the 
morning  of  Day  2,  a wrap-up  session  was  held  in  which  the  chair  of  each  working  group 
presented  a summary  of  their  findings.  During  the  afternoon  of  Day  2,  closing  remarks 
were  presented,  a discussion  period  was  held,  and  tours  of  NIST  knowledge-related 
facilities  were  conducted. 

1.5  Report  Scope  and  Contents 

The  preceding  sections  on  the  CIKS  program  goals  and  objectives  have  been  written  to 
provide  the  reader  with  information  the  CIKS  program  progress  up  to  the  time  of  the 
workshop.  The  remainder  of  this  report  focuses  on  the  presentations,  activities  and 
discussions,  and  conclusions  and  recommendations  resulting  from  the  workshop.  The 
appendices  serve  to  document  the  workshop  agenda  and  participation. 
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2.  KEYNOTE  PRESENTATIONS 


The  Link  between  Terminology  and  Data  Element  Dictionaries 

Sue  Ellen  Wright 

Kent  State  University  Institute  for  Applied  Linguistics 

1.  Introduction 

The  following  discussion  of  data  element  specifications  for  the  purpose  of  data 
interchange  is  based  on  the  author(s)  experience  in  creating  a data  element  dictionary  in 
the  context  of  ISO/TC  37,  Terminology  (Principles  and  coordination),  as  well  as  long- 
term involvement  with  terminology  standardization  in  association  with  the  ASTM 
Committee  on  Terminology  and  its  successor,  Technical  Committee  E02  for 
Terminology. 

Collecting  data  and  maintaining  data  collections  cost  money.  Given  the  availability  of 
substantial  data  collections  in  both  the  public  and  private  sectors,  exchange  of  data 
among  systems  opens  up  the  possibility  for  considerable  savings,  both  by  eliminating  the 
need  for  duplicated  research  and  data  entry  and  by  supporting  increased  efficiency  in 
cooperative  environments. 

Although  these  apparent  advantages  can  be  exploited  at  least  theoretically  in  materials 
databases  and  logistics,  in  every  aspect  of  computer  aided  design,  in  medical  diagnosis 
and  insurance  documentation,  in  military  administration  and  countless  other  fields  (not  to 
mention  terminology  documentation  itself),  data  incompatibility  has  in  the  past  posed  a 
serious  obstacle  to  the  realization  of  potential  benefits.  Nevertheless,  development  of 
such  standard  formats  as  the  universal  patient  record  and  the  MARC  record  are  moving 
information  management  in  the  direction  of  harmonization.  Such  formats,  however,  rely 
on  the  clear  specification  and  definition  of  the  categories  of  data  elements  that  are  used  in 
local  databases  so  that  data  can  be  interpreted  and  utilized  across  system  and 
organizational  boundaries. 

2.  Terminological  Aspects  of  Data  Elements 

2.1  Polysemy 

Data  incompatibility  can  be  described  with  respect  to  terminological  considerations. 
Starting  at  the  lowest  level  of  abstraction,  even  very  similar  data  elements  are  frequently 
defined  from  different  viewpoints,  are  assigned  different  scopes,  and  are  subject  to  data 
modeling  variance  in  the  context  of  data  architecture.  From  a terminological  perspective, 
they  can  be  said  to  be  subject  to  polysemy .' 

Polysemous  terms  are  represented  by  the  same  term  but  have  different  meanings,  i.e., 
the  concepts  they  represent  have  different  characteristics.  In  like  manner,  ambiguous 
data  elements  share  the  same  data  element  name,  but  they  have  slightly,  in  some  cases 
dramatically,  different  content.  These  differences  are  reflected  in  the  form  of  differing 
data  element  definitions  or  different  sets  of  data  element  attributes. 
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Of  course,  sound  database  management  practice  dictates  the  avoidance  of  multiple 
meanings  for  data  element  names,  so  one  can  expect  that  individual  databases  will  avoid 
this  kind  of  ambiguity  internally.  However,  as  soon  as  different  systems  (even  different 
independent  systems  within  the  same  organizational  entity)  are  linked,  variations  become 
evident.  Furthermore,  ambiguous  data  element  definitions  or  faulty  implementation  at  the 
data-entry  level  may  well  impair  data  integrity  and  prevent  effective  reuse  or  sharing  of 
resources. 

2.2  Synonymy 

Inadequate  tracking  of  objects  within  a database  can  also  result  in  the  assignment  of  more 
than  one  data  element  name  to  the  same  object.  This  kind  of  duplication  is  akin  to 
synonymy.  The  existence  of  such  doublettes  in,  for  instance,  materials  management 
modules  is  a major  source  of  unnecessary  inventory  management  cost  and  even  materials 
acquisition  error  and  expense.  Not  as  obvious,  but  perhaps  even  more  critical,  is  the 
absence  of  systematic  structure  in  many  object  management  systems.  A well-conceived 
item  master  listing  the  objects  managed  by  a system  can  reflect  a semantic  network  that 
represents  the  intrinsic  relations  that  exist  among  objects  in  the  system.  Put  more  simply, 
naming  and  numbering  systems  can  be  structured  so  that  they  reveal  the  answers  to 
questions  like:  Is  A a kind  of'Q  (generic  relation)?  Is  A a part  of  B (part-whole  relation)? 
Are  A and  B subsequent  steps  in  a process  C (sequential  or  possibly  cause  and  effect 
relation)? 

Incorporating  this  kind  of  conceptual  organization  into  data  structures  lays  the 
groundwork  for  data  management  systems  to  evolve  into  information  and  knowledge 
management  systems.  Unfortunately,  many  existing  systems  were  based  on  illogical  or 
arcane  criteria,  such  as  vestigial  reference  to  obsolete  project  numbers,  instead  of 
building  on  intrinsic  characteristics  such  as  species  identity  (e.g.,  related  bolt  designs), 
partitive  relations  (sub-assemblies  in  a major  component),  or  procedural  sequence  (oper- 
ations in  a process).  Systems  that  do  not  reflect  network  structures  not  only  increase 
current  data-management  costs;  they  also  shut  the  system  off  from  the  introduction  of 
more  intelligent,  inferential  systems  in  the  future. 

2.3  Terminological  Principles  for  Naming  Data  Elements 

The  logical  result  of  these  observations  is  that  master  data  files  should  be  subject  to  the 
same  criteria  that  are  dictated  for  standardized  terminology. 

□ One  and  only  one  data  element  name  is  assigned  per  data  element  concept. 

□ One  and  only  one  concept  is  associated  with  a given  data  element  name. 

□ (Terminologists  will  recognize  these  demands  immediately:  data  element  names,  like 
terms,  should  be  mononymous  and  monosemous.) 

□ Data  element  definitions  must  be  concisely  and  yet  adequately  formulated. 

□ Data  element  dictionaries  must  be  structured  in  logical  ways  that  reflect  meaningful, 
i.e.  semantic,  relations  among  data  element  concepts,  such  as  parent-child,  sibling,  or 
part-whole  relations. 

□ Data  element  dictionaries  should  clearly  distinguish  related  or  easily  confused  data 
elements  from  one  another. 
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Within  the  context  of  terminological  principles,  it  is  also  valuable  to  observe  the  fundamental 
differences  between  terminological  entries  and  lexicographical  ones.  The  chart  appended  to  this 
article  as  Annex  A illustrates  the  distinctions  between  these  two  methods  for  documenting  words 
and  meaning.  Within  the  framework  of  this  article,  it  is  especially  important  to  emphasize  the 
concept-oriented  basis  for  terminological  resources,  which  is  reflected  in  the  kinds  of  definitions 
that  must  be  associated  with  data  dictionaries  as  well. 

3.  The  Dangers  of  Implicit  Information 

Ambiguous  data  element  definition  and  inaccurate  data  entry  practices  may  not  be  critically 
problematic  as  long  as  a database  only  serves  as  an  information  repository  for  human  users 
because  humans  infer  additional  information  or  supplemental  organizational  orientation  based  on 
unstated,  i.e.,  implicit,  contextual  assumptions.  Furthermore,  information  entered  in  individual 
databases  may  well  be  quite  clear  in  its  own  immediate  environment,  but  the  potential  for 
ambiguity  arises  when  an  effort  is  made  to  merge  data  with  other  databases  designed  to  meet 
different  needs. 

These  potential  problems  become  more  critical  when  data  have  to  interact  efficiently  within 
automated  systems  or  when  they  must  be  automatically  exchanged  among  sub-systems  within 
the  same  network  or  among  different  autonomous  systems.  Traditionally,  automated  routines 
have  not  functioned  on  an  inferential  basis,  which  means  that  to  be  successfully  used  in  data 
interchange  environments,  data  structures  need  to  conform  to  one  of  possibly  three  options  for 
achieving  an  environment  where  all  participants  (systems)  have  the  same  understanding  of  the 
meaning  for  each  and  every  piece  of  data: 

□ All  systems  use  the  same  data  architecture. 

□ All  systems  have  access  to  each  other's  data  architecture  and  implement  the  appropriate 
translation  routines  to  interpret  data  appropriately. 

□ Unified  data  element  specifications  provide  the  information  needed  to  allow  for  inferential 
processing  by  intelligent  systems. 

Evaluation  of  the  costs  and  effort  involved  in  implementing  any  one  of  the  three  mechanisms 
leads  inevitably  to  the  conclusion  that  the  cost  of  implementing  the  first  option  would  be  patently 
prohibitive,  not  to  mention  the  fact  that  no  one  uniform  architecture  is  likely  to  meet  diverse 
needs  and  expectations.  Furthermore,  with  respect  to  the  second  option,  it  is  usually  a challenge 
to  any  work  group  simply  to  develop,  implement,  and  maintain  one  data  architecture,  let  alone 
track  other  architectures  as  well.  This  line  of  reasoning  leaves  us  with  the  final  option  of 
developing  unambiguous  data  element  specifications  that  offer  the  greatest  benefits  for  future- 
oriented  system  design. 


4.  Data  Element  Attributes 

Data  element  specifications  are  analogous  to  terminological  definitions.  A well-crafted  definition 
clearly  states  the  characteristics  that  it  shares  with  other  concepts  in  its  class  (shared  parent-child 
characteristics)  and  that  distinguish  it  from  other  closely  related  concepts  (differentiating  sibling 
characteristics).  In  like  manner,  data  element  specifications  disambiguate  data  elements  by 
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specifying  the  attributes  associated  with  each  data  element.  These  attributes  comprise  the 
minimum  information  required  for  unequivocally  identifying  data  elements. 

The  minimum  information  required  for  data  element  specifications  includes  the  designation  of 
the  data  element  name,  a statement  of  its  content,  and  the  formulation  of  an  adequate  definition. 
In  addition  to  these  features,  specification  of  any  given  data  element  can  include  information  on 
the  data  type  of  the  data  element,  a listing  of  permissible  instances  (content),  and  determination 
of  the  level  of  granularity  represented  by  a given  element  or  set  of  elements.  The  function  of 
data  elements  is  further  affected  by  such  practical  aspects  as  the  avoidance  of  redundancy 
through  the  creation  of  shared  resources,  data  element  autonomy,  data  modeling  variance, 
combinability,  repeatability,  and  interaction  with  existing  standards.  All  these  considerations 
affect  the  naming  and  the  definition  of  data  elements.  The  examples  cited  in  the  following 
discussion  are  taken  from  the  list  of  data  categories  (data  elements)  compiled  by  ISO/TC  37, 
Terminology  (principles  and  coordination)  (ISO  12620:1997;  Schmitz  1997). 

4.1  Data  Element  Definition 

Data  element  specifications  contain  definitions  as  one  of  their  principal  attributes,  although  some 
terminologists  prefer  to  talk  about  data  element  or  data  category  descriptions  instead  of 
definitions  in  order  to  distinguish  them  from  definitions  in  terminology  collections.  A data 
element  specification  may  stipulate  that  a particular  element  contains  xyz...,  but  it  is  also 
important  to  define  xyz  in  order  to  ensure  that  users  clearly  understand  what  the  content  of  the 
category  really  is,  (e.g.,  contains  xyz,  which  is  ...).  Definitions  can,  however,  reside  in  a parallel 
terminology  standard  where  they  can  be  referenced,  provided  that  they  are  all  in  the  same  place 
and  readily  accessible. 

Definitions  are  important  in  order  to  avoid  ambiguity.  For  instance,  in  terminology  databases  the 
data  elements  example  and  context  are  sometimes  confused  with  one  another.  Other  elements, 
such  as  the  terminological  data  element  transfer  comment  are  widely  used  in  some  work  groups 
but  unknown  to  other  terminologists.  A dictionary  of  data  elements  is  indispensable  for  mapping 
local  data  elements  to  standardized  data  elements  that  can  be  used  for  interchange  purposes. 
Such  definitions  should  ideally  meet  the  requirements  for  terminological  definitions  by  spelling 
out  the  relation  of  the  concept  represented  by  the  data  element  within  its  semantic  network  and 
distinguishing  each  data  element  from  closely  related  data  elements. 


4.2  Data  Type 

Data  element  dictionaries  can  also  specify  the  data  type  of  the  element,  e.g.,  free  text,  dates, 
numbers,  etc.  Data  type  designations  can  also  be  associated  with  references  to  standardized 
formats  for  representing  information,  such  as  standards  for  dates,  country  and  language  symbols, 
or  international  identification  numbers  used  as  bibliographical  references.  One  of  the  most 
common  forms  of  representation  is  to  require  the  use  of  specific  SI  units.  In  this  regard,  some 
databases  may  also  specify  field  length  for  such  standardized  elements,  although  more  and  more 
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knowledge-oriented  systems  are  moving  away  from  fixed  field  lengths,  especially  in 
terminological  and  bibliographical  resources. 

4.3  Permissible  Instances 

Restriction  of  element  content  to  a specified  data  type  and  standard  is  one  way  to  state  the 
permissible  instances  that  can  occur  in  that  data  element.  Another  way  is  to  create  a pick  list 
from  which  users  select  the  appropriate  content  for  any  given  case.  The  advantage  of  using 
defined  pick  lists  where  appropriate  is  to  prevent  generating  different  forms  for  representing  the 
same  meaning  or  introducing  undocumented  content.  For  instance,  a standard  could  require  that 
for  interchange  purposes,  part  of  speech  should  be  represented  as  n,  v,  adj,  adv.,  thus  ruling  out 
the  option  for  using  noun,  verb,  adjective,  and  adverb,  or  opting  for  substantive  instead  of  using 
noun.  The  advantage  of  this  degree  of  specification  is  that  merged  databases  will  exhibit  uniform 
content.  Validation  programs  can  be  used  to  check  to  ensure  that  candidates  for  interchange 
conform  to  the  standard. 

4.4  Granularity 

Examining  data  element  definitions  often  reveals  that  different  databases  treat  similar  data 
elements  in  different  ways.  For  instance.  Figure  1 illustrates  an  example  of  the  data  element 
address.  Figure  2 divides  the  same  information  into  finer  units.  In  order  to  ensure  that  the  correct 
data  are  input  into  any  of  the  fields  in  Figures  1 and  2,  or  that  users  can  interpret  these  data 
appropriately,  the  data  elements  must  be  clearly  defined  and  data  entry  must  conform  to  these 
definitions.  This  kind  of  difference  between  approaches  to  subdividing  information  is  commonly 
referred  to  as  granularity. 


Data  element 

Content 

Name 

John  Doe 

Address 

267  Prospect  St. 

Kent  Ohio  44240  USA 

Figure  1 : Minimum  granularity 
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Data  element 

Content 

Last  Name 

Doe 

First  Name 

John 

Street  Address 

267  Prospect  St. 

City 

Kent 

State 

Ohio 

Zip  Code 

44240 

Country 

USA 

Figure  2:  Increased  granularity 

The  data  modeling  scheme  followed  in  Figure  2 can  be  described  as  more  powerful  because  data 
that  are  categorized  in  this  way  can  be  more  easily  retrieved  or  manipulated.  For  instance,  the 
entry  shown  in  Figure  2 can  be  sorted  or  retrieved  by  the  last  name,  town,  state,  zip  code,  or 
country.  (Theoretically,  it  could  also  be  sorted  by  the  given  name,  but  this  application  is  probably 
rare.)  It  might,  however,  be  desirable  to  be  able  to  sort  by  street  name  and  number,  in  which  case 
the  data  element  street  address  could  be  subdivided  in  order  to  achieve  higher  granularity.  A 
typical  example  of  variation  in  granularity  in  a multilingual  terminological  data  element  involves 
the  decision  whether  to  include  all  grammatical  information  in  a grammar  data  element  or  to 
specify  part  of  speech,  gender  and  number  instead. 

Individual  database  systems  define  the  granularity  of  data  elements  in  keeping  with  perceived 
data  management  needs,  although  it  is  very  important  that  system  designers  think  through  these 
needs  carefully  when  modeling  data  in  order  to  ensure  that  the  structures  that  are  implemented  at 
the  outset  will  indeed  meet  future  requirements  for  data  manipulation  and  maintenance.  It  is 
important  to  bear  in  mind  that  in  interchange  environments,  differences  in  granularity  tend  to 
limit  data  reusability.  Allowing  for  broader  categories  facilitates  interchange  and  may  be  less 
expensive  (or  look  less  expensive  at  the  beginning  of  a project),  but  this  practice  reduces  power 
and  freedom  to  manipulate  data.  It  is  very  simple,  for  instance,  to  write  a conversion  routine  that 
would  combine  elements  in  Figure  2 to  fit  into  elements  in  the  database  represented  by  Figure  1, 
but  it  may  be  very  difficult,  if  not  impossible,  to  devise  an  automatic  way  to  split  the  elements 
shown  in  Figure  1 so  that  they  can  be  assigned  to  the  more  granular  model  shown  in  Figure  2. 
Thus,  when  planning  an  interchange  formalism  or  creating  a data  element  dictionary,  it  is 
desirable  to  indicate  the  degree  of  granularity  desired  for  automatic  interchange  when  defining 
data  elements. 

Some  instances  of  granularity,  such  as  the  address  example  cited  above,  reflect  the  needs  and 
philosophy  of  the  system  designers.  Other  choices,  however,  are  not  so  optional.  For  instance, 
the  inclusion  of  source  information  in  the  same  data  element  together  with  a text  field  or  even  the 
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inclusion  of  page  numbers  together  with  the  source  identifier  that  references  a shared  resource 
violates  the  essential  integrity  ( Sauberkeit ) of  the  database  and  prevents  efficient  manipulation  of 
data.  Special  attention  should  be  given  to  avoiding  shopping  basket  style  data  elements  such  as 
undifferentiated  notes  or  comments  that  can  result  in  many  different  kinds  of  information  being 
stored  in  the  same  data  element. 

4.5  Term  Autonomy  and  Data  Modeling  Variance 

The  principle  of  term  autonomy  is  particularly  relevant  to  termbases,  but  similar  situations  may 
also  exist  in  materials  databases.  Even  when  termbases  adhere  to  the  one-concept-per-entry 
dictum,  data  modeling  variance  from  one  system  to  another  often  results  in  non-uniform 
presentation  of  data.  For  instance,  in  a terminology  entry,  one  possible  presentation  is  to 
designate  a so-called  main  entry  term  in  a term  data  field,  while  other  terms  appear  in  other  data 
elements  such  as  synonym,  abbreviation,  and  the  like  (Figure  3a).  The  weakness  of  this 
particular  approach  is  that  it  frequently  fails  to  provide  the  option  to  include  complete 
documentation  for  each  additional  term  (Schmitz  1997). 


Term  Entry,  Data  Element 

Content 

Term: 

personal  computer 

Part  of  speech: 

Noun 

Definition: 

A computer  designed  for  personal  use. 

SourcelD: 

Oxford  1990 

Responsibility: 

SEW 

Abbreviation: 

PC 

Synonym: 

Microcomputer 

Term: 

personal  computer 

Part  of  speech: 

Noun 

Term  type: 

preferred  term 

Definition: 

A computer  designed  for  personal  use. 

SourcelD: 

Oxford  1990 

Term: 

PC 

Part  of  speech: 

noun 

Term  type: 

Abbreviation 
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Term  Entry,  Data  Element 

Content 

Context: 

PCs  are  now  common  in  all  office 
environments. 

SourcelD: 

Kluge 1997 

Term: 

microcomputer 

Part  of  speech: 

noun 

Term  type: 

synonym 

Definition: 

A computer  containing  a micropro- 
cessor as  the  CPU. 

SourcelD: 

Oxford  1990 

Responsibility: 

SEW 

Figures  3a  and  3b:  Data  modeling  variance 

Figure  3b  illustrates  a more  egalitarian  approach  that  reflects  the  view  that  all  terms  are  created 
equal.  Here  each  term  associated  with  a concept  is  reported  in  an  independent  term  element  that 
can  then  be  associated  with  its  own  data  segment  containing  such  subordinate  elements  as  part  of 
speech , gender , number , and  term  type.  It  is  here  where  information  such  as  synonym, 
abbreviation,  etc.  can  be  included  as  attributes  of  the  term.  Term  autonomy  is  closely  related  to 
the  principle  of  repeatability  and  combinability,  which  provides  for  the  reuse  of  data  elements 
and  the  establishment  of  internal  data  element  relations  within  individual  data  entries. 

4.6  Redundancy  and  Shared  Resources 

A cardinal  rule  of  database  management  is  that  redundancy  should  be  avoided.  For  instance,  it  is 
possible  to  include  complete  bibliographical  references  after  each  text  element  included  in  a term 
entry  (definitions,  contexts,  etc.),  but  if  an  error  occurs  in  a reference  or  information  needs  to  be 
updated,  it  becomes  necessary  to  find  each  citation  to  the  same  source  and  make  the  desired 
change.  Consequently,  it  is  more  economical  from  the  standpoint  of  database  management  to 
enter  the  bibliographical  reference  once  in  a single  bibliographical  entry  or  table  and  to  link  all 
the  individual  entries  that  cite  that  resource  to  a shared  bibliographical  entry.  This  approach  also 
contributes  to  efficiency  with  regard  to  increased  granularity  because  it  is  much  more  feasible  to 
enter  articulated  data  in  a single  bibliographical  entry  that  will  be  used  as  a shared  resource  than 
it  is  to  do  so  in  each  individual  term  entry.  The  treatment  of  these  kinds  of  shared  resources  in 
databases  impacts  the  content  of  function  of  the  data  elements  used  to  form  links  and  requires  the 
specification  of  data  elements  used  to  document  the  shared  resources  themselves. 
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Bibliographical  entries  are  not  the  only  kind  of  shared  resources  included  in  terminology  files. 
Termbases,  for  instance,  feature  links  from  term  entries  to  responsibility  entries,  graphics,  video 
and  audio  files,  tables  and  charts,  diagrams  of  concept  systems,  lists,  materials  management 
systems,  thesauri,  and  other  types  of  related  resources.  Other  kinds  of  databases  may  feature 
these  or  similar  shared  resources  as  well.  Shared  resources  may  reside  as  bundled  data  inside 
actual  databases  or  be  accessed  via  hypertext  links  to  other  file  types  residing  in  the  same  system 
or  accessible  via  network  connections. 

5.  Domain-specific  Subject  Field  Specifications 

The  unambiguous  interchange  of  almost  any  kind  of  terminological  or  knowledge-based 
information  is  predicated  on  the  presence  of  uniform  subject  classification  codes.  The  selection 
of  an  existing  coding  system  or  the  creation  of  a new  one  must  be  undertaken  by  or  in  close 
collaboration  with  experts  in  the  field  in  question.  Numerous  disciplines  have  developed  widely 
recognized  thesauri  for  data  retrieval  purposes  that  can  serve  this  purpose.  In  some  areas,  like 
medicine,  for  instance,  great  effort  has  been  invested  in  standardizing  a uniform  classification 
scheme  in  order  to  resolve  problems  involving  conflicting  systems.  Without  the  acceptance  of 
universal  context-oriented  domain  references  it  will  be  impossible  to  implement  context-oriented 
inferential  knowledge  systems  using  shared  data.  Terminologists,  information  scientists, 
translators,  and  technical  writers  frequently  serve  as  non-expert  manipulators  of  information- 
related  data.  They  need  to  be  able  to  depend  on  the  expert  knowledge  that  subject-field 
specialists  can  provide  by  creating  or  standardizing  a subject-specific  classification  system. 


6.  Coordinating  Data  Element  Standardization 

The  Joint  Technical  Committee  of  the  International  Standards  Organization  and  the  International 
Elect-Technical  Commission  (ISO/IEC  JTC  1/SC  14,  ISO  11179)  has  undertaken  to  develop 
standards  for  coordinating  data  element  standardization  designed  to  ensure  accurate,  reliable, 
controllable,  and  verifiable  data  recorded  in  databases.  They  are  currently  developing  a suite  of 
standards  dealing  with: 

□ Standardization  of  data  elements 

□ Classification  of  concepts  for  the  identification  of  domains 

□ Specification  of  data  element  attributes 

□ Formulation  of  data  definitions 

□ Naming  principles  for  data  elements 

□ Registration  of  data  elements 

These  topics  read  like  an  outline  for  terminology  management:  identification  of  data  element 
concepts  (concept  selection),  subject-field  classification,  the  identification  of  characteristics 
(attributes),  composing  adequate  definitions,  term  formation,  and  providing  repositories  of 
standardized  terms. 


14 


7.  Application  Environments 


The  developers  of  a data  element  dictionary  need  to  determine  for  themselves  whether  this 
activity  is  sufficient  to  meet  their  needs  or  whether  they  need  also  to  specify  a uniform 
interchange  format  or  a standard  data  structure.  The  developers  of  ISO  FDIS  12620,  Computer 
Applications  in  Terminology  Data  Categories  have  also  been  involved  in  the  development  of  an 
SGML  interchange  format,  ISO  FDIS  12200,  Computer  Applications  in  Terminology  Machine- 
Readable  Terminology  Interchange  Format  (MART1F)  Part  1:  Negotiated  Interchange.  The 
concept  of  negotiated  interchange  implies  that  database  managers  will  have  to  look  carefully  at 
the  data  they  are  importing  and  will  subject  that  data  to  various  validation  and  conversion 
routines  before  integrating  it  into  their  own  systems.  Indeed,  the  data  elements  in  the  source 
material  do  not  have  to  conform  to  the  standard  in  their  native  mode,  but  are  brought  into 
conformance  during  the  conversion  process. 

A debate  continues  in  TC  37  whether  it  is  not  more  desirable  to  standardize  a much  more 
stringent  so-called  generic  exchange  architecture  that  will  facilitate  a uniform  representation  of 
data  outside  their  original  database  environment.  The  purpose  of  such  a structure  would  be  to 
consolidate  terminological  data  into  a global  terminology  resource  in  the  Internet  environment. 
No  final  decisions  have  been  made  on  the  exact  appearance  of  such  a format,  and  it  may  well  be 
that  the  desirability  of  such  a uniform  expression  of  information  is  typical  only  to  terminology  or 
perhaps  bibliographical  records,  such  as  in  the  case  of  the  MARC  record.  Similar  discussions 
continue  in  the  lexicography  field  as  well,  although  there  appears  to  be  less  commonality  of 
viewpoint  in  that  area  than  among  the  terminologists. 

Regardless  of  the  environment  in  which  the  data  element  dictionary  will  be  applied,  the  need  to 
identify  and  define  the  data-element-related  terms  used  in  a discipline  is  an  essential  component 
of  a process  designed  to  create  a data  element  dictionary  for  the  purpose  of  ensuring  effective 
data  management  during  the  interchange  of  data  among  diverse  systems. 
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Annex  A:  Lexicographical  vs.  Terminological  Entries 


Lexicographical  Entry 

a Treats  a word  (frequently  called  a head- 
word) 

□ 

Treats  multiple  polysemic  senses  of  the 
word  based  on  one  etymological 
derivation 

Q Treats  homographic  words  with  different 
derivations  in  separate  entries 

□ 

Provides  all  grammatical  information  per- 
taining to  the  word 

□ 

Is  arranged  in  strict  alphabetical  order  for 
easy  access 

□ 

Describes,  or  at  most,  recommends  usage 

□ 

Usually  treats  words  as  a universal  set 
taken  from  general  language 

(Wright  and  Budin  1997:328) 


Terminological  Entry 

a Treats  a concept  and  is  sometimes  iden- 
tified by  a code  rather  than  a word 

□ 

Treats  one  concept  in  one  entry,  and 
documents  all  terms  assigned  to  that 
concept 

Treats  polysemic  meanings  of  the  same 
word  in  separate  entries 

□ 

Cites  only  those  grammatical  differences 
that  may  be  related  to  term-concept  as- 
signment 

° Often  is  arranged  according  to  a system- 
atic concept  structure,  with  alphabetical 
cross-listing 

□ 

Frequently  documents  preferred  or  recom- 
mended usage 

Treats  terms  belonging  to  a domain- 
specific  special  language 


Unfortunately,  the  terminology  used  with  data  element  dictionaries  themselves  involves  some  degree  of 
polysemy.  The  term  data  element  can  be  construed  as  either  a single  field  (a  data  element  instance  or  data 
element  item  or  it  can  be  viewed  as  a class  of  data  elements,  i.e.,  all  instances  of  a data  element  occurring 
in  a database.  In  the  terminology  community,  this  potential  for  confusion  has  led  to  the  evolution  of  the 
term  data  category,  which  is  defined  in  ISO/TC  37  standards  as  an  instruction  for  interpreting  a given 
data  field  (ISO  DIS  1087-2.2:  1997).  Unfortunately,  this  term  evolved  parallel  to  the  development  of  the 
term  data  element  in  English  parlance  and  can  cause  confusion.  For  purposes  of  this  audience  and  this 
paper,  I will  use  the  term  data  element  to  refer  to  a category  of  data  elements  and,  if  necessary,  data 
element  instance  to  designate  an  individual  instantiation  of  a data  element,  which  can  be  construed  as  a 
unit  of  data  that  in  a certain  context  is  considered  indivisible  (ISO  2382-4: 1987). 
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An  Intermediate  Model  for  Interoperation  of 
Web-distributed  Applications  With  A Design  Model 

James  Andrew  Arnold 
Stanford  University 


Abstract:  This  paper  defines  the  data  and  inference  requirements  for  the  interoperation  of 
analysis  applications  and  a product  model.  Application  inputs  often  require  sets  of  complex  data 
that  constitute  database  views  of  a product  model.  We  introduce  a method  that  works  with  the 
STEP  and  PLIB  product  description  standards  to  define  an  intermediate  model  that  assists 
interpretation  (selects  and  extracts  information),  and  validates  views  from  a product  model  for 
the  inputs  of  an  application.  This  research  built  and  tested  the  intermediate  model  framework  in 
a software  prototype,  the  Internet  Broker  for  Engineering  Services  (IBES).  It  integrates 
applications  that  specify  and  diagnose  faults  in  certain  components,  for  example  pumps  and 
valves.  Thus  the  research  scope  explores  a sub-set  of  the  general  problem  of  integrating  product 
data  semantics  between  engineering  applications.  This  research  suggests  that  it  is  possible  to 
define  a general  set  of  services  to  assist  interpretation  and  validate  information  from  a product 
model  for  an  engineering  purpose. 


Introduction 

The  World  Wide  Web  (Web)  and  related  network  technologies  comprise  an  infrastructure  for 
ubiquitous  information  exchange  and  eventually,  electronic  commerce  through  access  to  markets 
of  product  information  and  software  applications. 

To  date,  Web  applications  add  value  primarily  for  communication  and  publishing.  For  example 
Email  is  prevalent  and  many  applications  exist  to  create  Web  pages.  Applications  for  business 
transactions  are  in  the  early  adoption  phase.  Examples  include  procurement,  inventory  control, 
and  banking  services.  In  the  future  Web  applications  will  be  available  to  automate  core  business 
functions  and  leverage  them  across  organizations.  This  third  class  of  software,  often  categorized 
as  enterprise  computing  technology,  will  generate  the  greatest  impact  on  the  business  process 
because  it  formalizes  expert  knowledge  for  integration  and  reuse  between  organizations.  The 
presence  of  Electronic  Data  Interchange  (EDI)  and  electronic  banking  services  indicate  that  the 
representation  requirements  for  the  automation  of  basic  business  transactions  are  relatively  well 
understood.  However  automation  of  core  design  and  engineering  tasks  necessitates  additional 
capability  for  modeling  design  content  and  reasoning  to  enable  software  interoperation. 
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For  example,  consider  component  selection  for  a design  by  using  the  Web  to  integrate  a selection 
program  supplied  by  an  information  publisher  (a  product  vendor  or  dealer)  directly  with  a 
product  model  in  a CAD  system  developed  or  maintained  by  an  information  subscriber  (process 
engineer  or  facility  owner).  Throughout  this  paper  we  will  refer  to  a specific  case  of  this  problem 
involving  the  selection  of  a control  valve  for  a process  plant  sub-system.  Our  example 
demonstrates  automation  of  a routine  engineering  task  that  leverages  knowledge  between  a 
publisher  and  subscriber.  Furthermore,  it  highlights  the  functionality  for  modeling  design  content 
and  reasoning  that  we  believe  is  necessary  to  support  task  automation  within  an  interoperable 
computing  environment. 

We  use  the  term  component  to  denote  a complex  (assembled  part)  item  as  opposed  to  a part 
(single  item)  that  is  normally  manufactured  and  sold  by  a vendor  and  is  incorporated  into  the 
facility.  The  term  “component  model”  differentiates  this  information  model  from  a “product 
model”,  a computer-readable  description  of  design  information  that  describes  the  facility  itself. 
The  test  case  draws  from  a textbook  example  for  selecting  the  correct  valve  size  under  conditions 
of  turbulent  liquid  flow. 

An  eight-inch  schedule  30  pipe  has  a flow  of  a maximum  1,600  gpm  of  river 
water.  The  pressure  immediately  upstream  of  the  control  valve  is  27.9  psig,  or 
42.6  psia.  The  pressure  in  the  pipe  immediately  downstream  of  the  valve  is  20 
psig,  or  34.7  psia.  Select  and  size  an  appropriate  control  valve.7 


The  problem  statement  gives  the  design  conditions  of  an  operating  case  to  compute  the  required 
coefficient  of  flow18,  Cv  (required)  = 569.  If  a design  engineer  wishes  to  use  a 60-degree 
butterfly  valve,  a 6”  nominal  diameter  valve  satisfies  the  requirements.  This  solution  is  obtained 
by  entering  the  design  condition  variables  into  publisher’s  product  selection  program,  or  by 
computing  the  Cv  manually  and  inspecting  the  proper  selection  table  in  a publisher’s  product 
catalog. 

Control  valve  selection  is  a typical  engineering  task  that  often  requires  information  exchange 
between  a product  vendor  and  design  engineer.  While  the  solution  for  the  example  is  simple,  the 
problem  statement  abstracts  the  knowledge  work,  the  context  of  information  gathering, 
organization,  analysis  and  evaluation  that  the  task  requires.  Today,  much  of  this  information  is 
located  in  non-integrated  spreadsheets,  equipment  databases,  CAD  drawings,  and  project 
specifications.2  In  the  future  such  information  will  be  formalized  in  a product  model. 

This  research  tests  the  hypothesis  that  a general  set  of  services  can  be  defined  to  support 
interoperation  and  integration  of  a CAD  system  incorporating  an  underlying  product  model  with 
an  engineering  analysis  program.  These  services  must  select,  extract,  validate  and  communicate 
information  from  a product  model  for  a software  program.  Figure  1 illustrates  the  research 
objective  in  terms  of  an  IDEFO  diagram.  The  product  model  is  the  input  to  the  integration 
activity.  The  output  is  the  validated  information  for  an  application’s  input  arguments.  The 
constraint  on  the  activity  is  the  vocabulary  that  delineates  the  expressiveness  of  the  intermediate 
model.  The  method  for  the  integration  activity  consists  of  logic  to  support  information  selection, 
extraction,  validation  and  communication.  Generalization  of  the  integration  activity  constraints 
and  methods  enables  integration  of  distinct  product  models  and  engineering  applications  which, 
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in  principle,  lowers  the  cost  of  integration  between  any  given  publisher  and  subscriber.  We 
envisage  these  services  as  middle- ware  that  will  be  implemented  on  top  of  a distributed  object 
protocol,  such  as  the  Common  Object  Request  Broker  (CORBA)16  or  the  Microsoft 
ActiveX/Distributed  Common  Object  Model  (DCOM)17,  and  function  as  an  engineering  content 
broker.  Thus  we  named  the  proof-of-concept  prototype  the  Internet  Broker  for  Engineering 
Services  (IBES). 

This  paper  is  organized  as  follows.  The  next  section  briefly  summarizes  related  AEC  product 
modeling  research;  Section  3 introduces  the  IBES  conceptual  framework  and  Section  4 furnishes 
a step  by  step  description  of  the  integration  services  provided  by  IBES.  Each  step  is  presented  in 
terms  of  a process  description  for  the  test  case  and  the  underlying  system  functionality.  The 
paper  concludes  with  a brief  description  of  the  implementation  platform  used  for  the  research 
and  a summary  discussion. 


Related  Work 

Historically  Architecture,  Engineering,  Construction  (AEC)  product-modeling  research  has 
focused  on  the  semantic  definition  and  structure  of  information  models  to  describe  facilities  and 
exchange  them  between  design  consultants. 1,3,6  Other  research  has  emphasized  data  structures  and 
database  management  systems  that  support  model  evolution  and  change  over  the  project  life 
cycle.8,9,10  Recent  research  emphasizes  product  model  formulation  as  an  outgrowth  of  a cognitive 
design  process.  Clayton  describes  a software  prototype,  called  the  Semantic  Modeling  Extension 
(SME),  that  provides  a human  computer  interface  and  modeling  environment  for  ‘interactive 
interpretation’,  the  user-initiated  mapping  of  graphical  features  (forms)  from  a CAD  drawing  to  a 
product  model  for  design  analysis  relevant  for  architectural  practice.5  Our  research  explores 
computer  automation  of  interpretation  in  the  context  of  an  existing  product  model  and  typical 
engineering  analysis  tasks. 

Distinct  representation  requirements  for  the  design  disciplines  are  leading  new  modeling  efforts 
to  explore  model  interoperation.  For  example,  the  Industry  Alliance  for  Interoperability  has 
committed  to  publication  of  the  Industry  Foundation  Classes  (IFC)  in  the  CORBA  Interface 
Definition  Language  (IDL).16  The  IFCs  define  object  hierarchies  of  building  components  and 
could  eventually  become  the  basis  for  a distributed  AEC  object  environment.  The  Standards  for 
the  Exchange  of  Product  data  (STEP)  community  has  begun  to  address  STEP  instance  data 
access  through  languages  and  tools  like  EXPRESS-X23  and  the  Standard  Data  Access  Interface 
(SDAI)  implementation  in  Java.14  These  tools  enable  the  definition  of  static  views  and  queries  of 
a STEP  model  from  distributed  locations. 

A reference  library  for  components  has  become  another  important  research  topic  for  object 
interoperation.  The  ISO  Parts  Library  Standard  (PLIB)  represents  the  leading  effort  to  date  in 
this  area.20,21,22  We  selected  the  PLIB  vocabulary  to  describe  the  semantics  of  the  IBES 
intermediate  model  because  of  its  resources  for  modeling  complex  engineering  information 
independently  of  a design  context.  This  paper  describes  just  a few  key  elements  of  the  PLIB 
conceptual  model  that  are  relevant  to  the  IBES  research. 

PLIB  defines  a semantic  dictionary  that  is  populated  by  dictionary  elements.1'  A dictionary 
element  describes  a semantic  concept  at  any  level  of  granularity,  for  example  a component,  a 
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property  of  a component,  or  a view  of  a component  from  a product  model.  Entries  in  the 
dictionary  are  associated  with  an  absolute  identifier,  called  a basic  semantic  unit  (BSU)  that  is 
sub-typed  by  identifier  category,  for  example  by  publisher  or  component  class.  The  dictionary 
supports  relations  between  entries  that  permit  specialization,  aggregation,  association,  and  cross- 
reference  of  dictionary  elements  and  thus  furnish  a basis  for  the  structured  representation  of 
complex  engineering  information.20  Data  stored  or  referenced  by  a dictionary  is  represented  as  a 
content  item  that  is  sub-typed  according  to  different  content  representation  types,  for  example  a 
single  value,  range  of  values,  table,  etc.  Content  items  have  a relation  to  their  description  in  the 
dictionary  through  the  basic  semantic  unit  identifier.  The  partition  of  content  representation 
from  the  dictionary  description  provides  a mechanism  to  define  a reference  model  for 
components  and  to  change  the  logical  description  (through  product  catalogue  updates,  etc.) 
without  affecting  the  semantic  definition.  It  also  permits  several  publishers  to  cross-index  their 
offerings  with  a reference  model  of  their  choice,  for  example  the  CSI  MasterFormat 
classification  system. 

PLIB  provides  the  resources  to  describe  a component  as  a discrete  object  in  a library  and  in 
terms  of  its  placement  in  a product  model  or  design  context.  The  library  structure  defines  a 
component  in  terms  of  three  object  topologies,  a general  model  description  (component  feature 
and  material  definition),  functional  model  description  (context  parameter  definition)  and 
associated  views  (functional  model  representation). 

The  dictionary  elements  that  represent  component  attributes,  called  properties , have  a relation  to 
a property  data  element  type  (property _det)  that  defines  a property’s  characteristics. 
Specialization  of  the  property_det  class  to  non  dependent,  context  dependent,  and  dependent  sub- 
types  permits  explicit  differentiation  of  a component’s  discrete  features  and  context  parameters 
that  are  derived  from  its  placement  in  a product  model. 

PLIB  furnishes  suitable  representation  structures  for  the  IBES  intermediate  model  and 
component  repository  because  of  the  resources  to  define  a semantic  dictionary  that  describes 
components  and  functional  views  of  components.  We  use  the  PLIB  resources  to  describe  and 
classify  engineering  analysis  applications  according  to  the  tasks  they  automate  as  they  relate  to 
components.  IBES  also  extends  the  PLIB  library  concept  by  adding  the  inference  rules  and 
intermediate  model  semantics  to  facilitate  a general  method  for  integration  of  an  engineering 
application  with  a CAD  system. 


IBES  Overview 

IBES  defines  data  types  and  provides  rule-based  inference  to  define  an  intermediate  model  that 
translates  engineering  content  between  a CAD  model  and  a software  application  for  component 
analysis.  The  intermediate  model  furnishes  a common  vocabulary  to  describe  information  from 
distinct  knowledge  sources,  a product  model,  and  a software  application.  This  research  assumes: 

• A CAD  environment  that  incorporates  a standard  product  model  representation  providing  a 
basis  for  agreement  on  product  data  semantics.  Emerging  product  description  standards  are 
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maturing  to  a level  where  their  use  is  feasible  in  certain  domains,  for  example  the 
development  of  STEP  models  for  the  process  industries.19 
• A marketplace  of  Web-distributed  software  applications  that  automate  and  support 
engineering  tasks  across  the  facility  life  cycle. 

Given  these  premises,  the  IBES  model  performs  the  following  primary  tasks: 

A.  Assists  interpretation5  of  a product  model  to  formulate  data  views  for  inputs  to  an 
engineering  application.  Assisted  interpretation  denotes  computer-supported  selection  and 
extraction  of  component  forms,  functions  and  behaviors  from  a product  model  representation 
to  a sharable  view  that  furnishes  the  input  for  analysis  and  evaluation; 

B.  Validates  the  view  data  and  software  inputs  to  determine  whether  there  is  correct  and 
sufficient  information  to  run  the  service; 

C.  Provides  a user  interface  that  flags  incomplete  and  mismatched  data,  and  allows  the  user  to 
take  corrective  action  to  modify  property  characteristics,  and  dynamically  update  the  view 
validation  status. 

D.  Furnishes  a message  interface  to  communicate  with  the  remote  application  when  it  requests 
additional  information  for  multi-step  reasoning,  and  presents  the  request  through  a graphical 
user  interface. 

Figure  2 diagrams  the  IBES  conceptual  model  framework.  The  clear  boxes  represent  the  primary 
objects  of  the  intermediate  model.  They  include  the  Application  Requirement  Template,  Product 
Model  View,  Product  Model  Map,  and  Service  Manager.  The  vectors  in  Figure  2 represent  the 
tasks  (A-D)  described  above.  They  include  assisted  interpretation  (A)  using  a Map  to  derive  a set 
of  Product  Model  Views.  Semantic  validation  (B)  between  an  Application  Requirement 
Template,  (the  specification  of  the  inputs  for  a class  of  engineering  application)  and  a set  of 
Views.  The  Control  step  (C  & D)  represents  the  user-interaction  processes  to  resolve  incomplete 
information  and  supply  additional  data  when  requested  by  the  application. 

The  conceptual  framework  to  support  tasks  (A)  and  (B)  was  adapted  from  the  heuristic 
classification  method  described  by  Clancey.4  IBES  also  layers  a human/computer  interface  over 
the  inference  framework  to  permit  user  interaction  with  the  broker  in  support  of  tasks  (C)  and 

(D). 

Clancy’s  study  of  expert  system  applications  identifies  a common  modeling  framework  for 
problems  that  involve  design  and  diagnosis.  He  notes  that  successful  expert  systems  abstract 
domain  data  to  a set  of  concepts  that  map  to  a hierarchy  of  pre-enumerated  solutions  by  non- 
hierarchical,  heuristic  inference.  The  solutions  are  then  refined  within  their  hierarchy. 
Knowledge  abstraction  to  a common,  intermediate,  and  context  independent  model  has  also  been 
explored  in  other  research.  For  example  Maluf  and  Wiederhold  develop  an  ontology  algebra  that 
combines  knowledge  from  distinct  sources  for  interoperation  and  manipulation.25 
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Heuristic  Classification 

IBES 

Domain  data 

Product  model 

Conceptual  abstraction  to 
problem  class 

Assisted  Interpretation  to  generate 
Product  Model  Views  that  contain 
information  selected  from  a product 
model  and  satisfy  the  information 
requirements  of  an  Application 
Requirement  Template 

Heuristic  match  between 

problem  class  and  pre- 
enumerated solution  class 

Semantic  validation  between  the 
properties  of  an  Application 

Requirement  Template  and  the 
properties  for  a set  of  Product  Model 
Views. 

Refinement  to  specific  solution 

Reference  from  an  Application 
Requirement  Template  to  a specific 
engineering  application  that  automates 
an  engineering  task. 

Table  1:  Correlation  of  heuristic  classification  terms  with  IBES  objects 


Table  1 relates  heuristic  classification  terms  to  the  IBES  framework.  Domain  data  correlates  with 
a product  model.  The  heuristic  classification  abstraction  step  correlates  with  assisted 
interpretation  in  which  IBES  selects  and  extracts  product  model  information  to  a data  view  that 
satisfies  the  specification  of  an  Application  Requirement  Template.  Heuristic  match  correlates 
with  the  IBES  semantic  validation  step  in  which  the  properties  of  a Product  Model  View  are 
validated  against  their  Application  Requirement  Template  specification.  The  refinement  step  of 
heuristic  classification  correlates  with  the  reference  from  an  Application  Requirement  Template 
to  a specific  publisher’s  engineering  application  based  on  business  and  contractual  requirements 
for  a given  project.  IBES  provides  this  reference,  however  it  does  not  infer  the  application  from 
business  rules  at  this  time. 


Using  IBES 

This  section  describes  how  IBES  works  for  the  test  case.  The  discussion  follows  the  process 
diagram  (Figure  3)  that  shows  the  flow  of  the  IBES  automation  tasks  (A-D)  described 
previously. 

It  was  noted  above  that  the  IBES  framework  depends  on  a standard  product  model  description. 
Figure  4 shows  the  CAD  representation  of  a fragment  of  the  Process  and  Instrumentation 
Diagram  (P&ID)  used  in  the  test  case  and  the  IBES  Service  Dialog  box  (described  below).  The 
product  model  underlying  the  CAD  representation  is  based  on  a small  subset  of  an  object  model, 
the  Activity  Resource  Model  (ARM),  of  the  STEP  standard  for  plant  spatial  configuration, 
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Application  Protocol  227  (AP227).19  The  IBES  adaptation  of  the  product  model  describes  three 
object  topologies,  a functional  description  of  a piping  sub-system,  the  associated  operating  cases 
for  the  process  material  and  design  parameters,  and  the  physical  components  (pipes,  pumps, 
valves,  etc.).  It  also  provides  relations  between  the  physical  and  functional  representations.  The 
prototype  includes  essentially  one  piping  sub-system  composed  of  several  pipe  segments,  a 
control  valve,  one  stream  definition  and  operating  cases  for  minimum,  maximum,  and  upset 
(abnormal)  flow  conditions.  These  topologies  contain  the  information  for  an  interpretation  that 
selects  and  extracts  information  for  control  valve  selection. 


Assisted  Interpretation 

The  IBES  automation  process  begins  with  assisted  interpretation  (Figure  3,  task  A).  The  product 
model  is  the  input  for  this  task.  We  begin  with  a discussion  of  the  task  constraints,  followed  by 
the  method,  and  end  with  a description  of  the  task  output,  a set  of  Product  Model  Views. 

The  IBES  system  constrains  assisted  interpretation  for  a particular  engineering  task  through  a 
human  computer  interface  for  the  CAD  system  that  permits  the  user  to  pick  a component  and 
then  an  engineering  application  that  is  registered  for  the  component  class  in  the  IBES  library.  For 
the  test  case  the  user  selects  a control  valve  symbol  from  the  P&ID,  and  then  the  preliminary 
sizing  application  from  a pop-up  dialog  box  (Figure  4). 

Once  the  system  determines  the  class  of  engineering  application  selected  by  the  user,  it  initializes 
the  appropriate  intermediate  model  instances  to  constrain  and  support  an  interpretation  query. 
The  query  searches  product  model  data  structures  for  information  that  corresponds  to  the  inputs 
of  an  engineering  analysis  application  as  specified  by  an  Application  Requirement  Template.  If 
the  query  finds  a product  model  data  item  for  an  Application  Requirement  Template  property 
specification,  it  translates  the  item  to  an  appropriate  Product  Model  View  property  content  item 
and  property  det  instance. 

The  upper  portion  of  Figure  5 shows  the  IBES  intermediate  model  class  definitions  that  were 
introduced  conceptually  in  Figure  2.  The  lower  part  of  Figure  5 shows  the  object  instances 
initialized  for  the  test  case.  These  objects  are  described  in  the  following  3 sections. 

□ Application  Requirement  Template 

An  Application  Requirement  Template  is  a wrapper  that  defines  the  engineering  function  and 
specifies  the  data  required  by  an  application.  In  principle,  the  Application  Requirement  Template 
topology  in  the  IBES  library  is  structured  according  to  a functional  decomposition  hierarchy  of 
engineering  tasks27.  For  the  test  case,  the  Application  Requirement  Template, 
cvSelectionTemplate,  is  simply  a direct  child  of  the  IBES  abstract  class 
applicationRequirementsTemplate,  which  itself  is  a child  of  the  PLIB  dictionary _element  class 
(not  shown  in  Figure  5). 

The  value  of  the  Application  Requirement  Template  definition  attribute  describes  the 
engineering  function  for  an  application.  For  the  cvSelectionTemplate  instance  the  value  of  this 
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attribute  is  ‘Template  for  control  valve  sizing’.  The  list  attribute  described _by  provides  the 
specification  of  properties22  required  for  control  valve  sizing. 

Each  property  of  an  Application  Requirement  Template  has  a code  (property  name)  and  a 
relation  to  a property_det22  instance  that  describes  the  domain  and  unit  characteristics  of  the 
property.  The  Inlet _Pressure  property  instance  in  Figure  5 relates  to  a conditional  property _det 
that  has  the  value  ‘real  measure_type’  for  domain  and  ‘psi’  for  unit.  The  Inlet _pressure  property 
instance  relates  to  a conditional  property_det  because  its  value  is  a context  parameter  selected 
from  the  operating  cases  for  the  piping  sub-system  in  the  product  model.  If  it  had  been  a 
dependent  det,  it  would  specify  the  property  det  objects  upon  which  it  depends  and  the 
derivation  function.  Property  characteristics  furnish  the  semantic  context  for  the  validation  of 
information  selected  from  the  product  model,  described  in  the  Section  titled  “Validation.” 

□ Product  Model  Map 

A Product  Model  Map  provides  two  levels  of  constraint  for  assisted  interpretation.  First,  it 
indicates  to  the  system  which  query  expressions  to  apply  for  a given  product  model  schema  and 
Application  Requirement  Template.  Second,  it  is  a control  object  for  a query  search. 

The  conceptual  object  diagram  in  Figure  2 indicates  the  coordination  purpose  of  the  Product 
Model  Map  class  by  showing  it  as  a constraint  object  for  the  interpretation  relation.  Similarly 
the  process  diagram  in  Figure  3 shows  the  Product  Model  Map  class  as  a constraint  for  assisted 
interpretation.  Figure  6 indicates  the  constraint  relationship  explicitly  for  the  test  case.  It  shows 
how  a Product  Model  Map  connects  the  AP227  schema  and  the  cvSelectionTemplate  class  with  a 
query  expression  file.  Thus  a Product  Model  Map  defines  the  applicable  context  of  an 
interpretation  query.  A publisher  would  need  to  define  a Map  and  a set  of  query  expressions  for 
each  type  of  application  multiplied  by  the  number  of  standard  product  model  schemata  that  it 
supports. 

While  query  expressions  depend  on  a product  model’s  data  structure,  constraints  such  as  start 
and  goal  objects,  and  intermediate  variables,  can  be  abstracted  and  referenced  as  attributes  of 
context  independent  control  objects.  The  list  attributes  query  ^variables  and  control  ^arguments 
of  the  Product  Model  Map  class  serve  this  purpose.  For  example,  the  control  valve  instance 
selected  by  the  user  provided  the  initial  state  for  the  model  search  of  the  test  case.  Its 
identification  attribute  value  was  referenced  in  the  query  variables  attribute  of  the  Product 
Model  Map  instance.  To  find  inlet  pressure  data,  the  query  searched  the  piping  circuit  upstream 
of  the  selected  valve  symbol,  skipping  intermediate  objects  such  as  a pipe  connector  until  a pipe 
segment  was  identified  for  which  operating  cases  that  supplied  inlet  pressure  information  could 
be  found.  During  the  search,  the  Product  Model  Map  referenced  the  pipe  connector  instance  in 
the  control  arguments  attribute  for  comparison  against  the  goal  object  of  the  query. 

Product  model  query  expressions  provide  the  method  to  select  and  extract  information  for 
assisted  interpretation  (Figure  3,  task  A).  Since  the  schema  of  a STEP  model  is  statically  defined, 
the  query  expressions  for  a particular  interpretation  may  also  be  pre-determined. 
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□ Product  Model  Views 


The  output  of  assisted  interpretation  is  a set  of  Product  Model  Views  that  provide  input  data  for 
the  engineering  analysis  application  (Figure  3,  task  A).  Several  Views  are  required  by  an 
application  when  a range  of  component  behaviors  must  be  computed  for  distinct  design 
conditions.  An  Application  Requirement  Template  specifies  the  default  Views  that  are  required 
by  an  application,  however  there  are  cases  in  which  the  product  model  contains  incomplete  or 
extra  information.  The  broker  handles  these  requirements  and  generates  Views  dynamically.  We 
discuss  how  IBES  handles  incomplete  information  in  the  section  titled  “Assisted  Interpretation.” 

IBES  initializes  Product  Model  View  instances  by  copying  information  from  the 
CvSelectionTemplate  instance.  The  description  and  number  of  default  Product  Model  Views  are 
obtained  from  a software  interface  object  provided  by  an  application  publisher.  Figure  5 shows  a 
representative  instance  of  a Product  Model  View  with  the  value  ‘vl’  for  the  identified_by 
attribute  and  ‘Minimum  Flow’  for  the  definition  attribute.  The  diagram  also  shows  the 
Inlet _Pressure  property  instance  and  its  relation  to  a content_item  instance  with  the  value  ‘20.0’ 
for  the  value  attribute.  The  diagram  also  shows  the  relation  to  a conditionaI_det  instance  that 
holds  the  property’s  characteristics  obtained  from  the  product  model. 

Figure  7 shows  the  graphical  user  interface  presented  to  the  user  after  the  system  has  queried  the 
product  model  for  the  test  case.  The  tree  view  control  on  the  left  displays  the  component  family 
and  specific  class  selected  by  the  user.  The  tabbed  dialog  box  displays  five  views  generated  by 
the  system.  Four  of  them  are  the  default  views  required  by  the  application  for  minimum, 
maximum,  and  upset  material  operating  cases,  and  a view  of  normalized  or  common  data.  The 
fifth  view,  UPSET  1,  indicates  that  the  query  detected  an  additional  operating  case  in  the  product 
model  and  IBES  generated  a view  for  it.  The  tabbed  dialog  box  also  shows  the  properties  for  the 
selected  view,  Specific  Gravity,  Stream_Phase,  etc.,  the  characteristics  of  each  property,  and 
their  validation  status.  Selecting  a property  from  the  list  box  lets  a user  inspect  its  characteristics 
in  the  edit  controls.  The  characteristics  for  the  Inlet -Pressure  property  are  displayed. 

Validation 

The  set  of  Product  Model  Views  generated  by  a query  provides  the  input  for  the  property 
validation  task.  The  Application  Requirement  Template  specification  provides  the  constraints, 
while  the  IBES  validation  algorithm  furnishes  the  method  (Figure  3,  task  B). 

The  IBES  validation  mechanism  for  assisted  interpretation  supports  the  viewpoint  that  most 
learned  behavior,  once  mastered,  becomes  implicit  for  the  performer.  The  user  modifies  a data 
item  only  when  an  interruption  or  breakdown28  occurs  from  identifying  incomplete  or  inaccurate 
information  during  interpretation,  and  when  the  application  requires  additional  information  to 
support  multi-step  reasoning.  Otherwise,  the  interpretation  activity  itself  is  transparent  for  the 
user. 

Before  the  user  can  invoke  the  application,  each  Product  Model  View  property  must  satisfy  its 
validation  constraints.  For  example  the  code,  domain  and  unit  attributes  for  the  Inlet  Pressure 
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property  instance  (Figure  5)  must  match  the  property  specification  defined  by  the  Application 
Requirement  Template  instance. 

Property  characteristic  validation  assures  that  information  obtained  from  the  product  model  is 
relevant  and  sufficient  for  invoking  the  analysis  application.  To  accommodate  user-initiated 
changes  to  property  characteristics,  the  validation  process  must  also  be  dynamic. 

The  IBES  implementation  of  the  validation  procedure  is  comprised  of  backward  chaining  rules 
that  pattern  match  the  data  between  the  specification  of  an  Application  Requirement  Template 
and  its  Product  Model  View  property  characteristic  values.  Since  Application  Requirement 
Template  and  Product  Model  View  representations  abstract  information  from  an  implementation 
context,  the  validation  algorithm  is  general  for  any  Product  Model  View- Application 
Requirement  Template  relation. 

To  control  rule  activation,  IBES  defines  objects  called,  respectively,  a property  match  controller, 
view  match  controller,  and  service  match  controller,  that  monitor  the  state  of  the  validation 
process.  A modification  or  change  to  the  value  of  a characteristic  changes  an  associated  control 
object  via  dependency  rules.  The  state  of  the  control  objects,  in  turn,  governs  the  activation  of 
the  validation  rules.  The  state-based  nature  of  rule  activation  permits  the  validation  process  to  be 
dynamic. 

Figure  8 is  a conceptual  flow  diagram  of  the  IBES  validation  algorithm  for  the  test  case.  Initial 
activation  of  the  validation  rule  set  begins  with  the  goal  to  invoke  the  preliminary  valve  sizing 
application.  A service  match  controller  monitors  the  satisfaction  of  this  goal  by  indicating 
whether  all  the  Product  Model  View  instances  generated  by  the  query  ‘match’  the  specification 
furnished  by  the  cvSelectionTemplate  instance.  A specific  Product  Model  View  instance,  for 
example  ‘vl’  (Figure  5),  is  ‘matched’  when  all  its  properties,  for  example  the  Inlet  Pressure 
property  instance,  ‘match’  their  Application  Requirement  Template  property  specification.  A 
view  match  controller  monitors  the  satisfaction  of  this  sub-goal  for  each  Product  Model  View 
instance.  Similarly,  a property  is  validated  when  all  its  characteristic  values  match  their 
specification.  For  example,  the  values  ‘real_measure_type’  and  ‘psi’  for  the  domain  and  range 
characteristics  of  the  Inlet  Pressure  property  instance  must  match  with  their  Application 
Requirement  Template  specification.  A property  match  controller  monitors  the  satisfaction  of 
this  sub-goal  for  each  property  instance. 

The  state-based  nature  of  the  algorithm  allows  for  the  easy  identification  of  incomplete  and 
mismatched  data  and  the  invocation  of  the  application  according  to  the  successful  match  of  the 
underlying  data.  The  next  section  describes  how  the  match  rules  are  integrated  with  the  user 
interface  to  enable  user  control  of  the  broker. 


User-initiated  control 

As  discussed  in  previously,  IBES  supports  user  input  to  resolve  incomplete  information  and 
provide  additional  information  for  multi-step  reasoning  (Figure  3,  Tasks  C & D).  The  following 
sections  discuss  how  IBES  meets  these  objectives. 
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□ Incomplete  Information 


The  IBES  system  must  respond  reasonably  to  incomplete  information  or  information  that  does 
not  match  between  a View  and  Application  Requirement  Template.  An  example  of  information 
mismatch  would  be  metric  versus  English  unit  representation  for  the  Inlet  Pressure  property  of 
the  test  case.  The  baseline  response  of  IBES  to  incomplete  information  is  to  query  the  user  and 
update  the  View. 

As  per  the  validation  step,  the  IBES  process  for  flagging  incomplete  information  takes  as  input 
the  set  of  Product  Model  Views  formed  by  the  query  and  is  constrained  by  the  data  specification 
of  the  Application  Requirement  Template  (Figure  3,  Task  C).  The  method  for  this  process 
integrates  the  validation  algorithm  with  a transaction  model  for  changing  property  characteristics 
through  the  user  interface.  The  output  of  this  process  is  a validated  and  resolved  set  of  Product 
Model  View  instances  ready  for  transmission  to  the  engineering  analysis  program. 

For  example,  the  possible  validation  states  for  the  Inlet  ^Pressure  Unit  characteristic,  ‘psi’,  can 
be  ‘matched’,  ‘not  matched’  and  ‘unknown’.  The  validation  algorithm  flags  the  unit 
characteristic  ‘matched’  or  ‘not  matched’  depending  whether  it  pattern  matched  with  the 
Application  Requirement  Template  specification  for  this  characteristic.  The  Service  Manager 
GUI  (graphical  user  interface)  (Figure  7)  indicates  the  match  status  where  the  user  can  make 
modifications.  The  checked  box  for  the  Inlet  Pressure  Unit  characteristic  indicates  that  the  value 
‘psi’  was  matched.  An  unchecked  box  would  indicate  ‘not  matched’,  while  a grayed  check  box 
would  indicate  the  match  status  is  ‘unknown’.  After  making  a modification,  for  example  by 
changing  the  Unit  value  from  ‘psi’  to  ‘N/m2’,  the  match  status  changes  to  ‘unknown’.  When  the 
user  presses  the  Apply  button  the  system  commits  the  latest  changes  to  the  underlying 
characteristic  instances.  As  discussed  above,  doing  this  causes  the  validation  rules  to  activate 
and  re- validate  the  Product  Model  View  data. 

□ Multi-step  reasoning 

Often  analysis  applications  perform  multi-step  reasoning  and  require  additional  data  from  the 
subscriber  (Figure  3,  Task  D).  This  requirement  indicates  a need  for  a communication  language 
that  supports  dynamic  exchange  of  structured  information  like  STEP  data,  and  associated  format 
information  to  enable  appropriate  presentation  to  the  user. 

IBES  addresses  this  requirement  for  the  valve  selection  test  case  with  a message  interface  that 
permits  limited  two-way  communication.  After  opening  a connection  to  a server,  IBES  can  send 
two  messages,  a Service  Request  and  an  Additional  Data  Response.  It  also  receives  two 
messages,  a New  Data  Request  and  Report  Transmission.  When  IBES  sends  a Service  Request  it 
transmits  View  data  to  the  server  for  processing.  It  sends  an  Additional  Data  Response  after  it 
receives  an  Additional  Data  Request  from  the  server  and  queries  the  user  for  the  information. 
Currently,  this  function  is  available  only  for  querying  a single  attribute  value  per  message.  It  is 
used  in  the  valve  selection  test  case  when  the  remote  service  queries  the  user  to  obtain  a value  for 
the  valve  port  nominal  diameter.  When  IBES  receives  a Report  Transmission,  it  presents  the 
information  to  the  user  through  the  Service  Manager  GUI. 
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Implementation 


The  IBES  prototype  currently  consists  of  three  sub-systems,  a CAD/Product  model,  IBES  model, 
and  analysis  applications  residing  on  a server.  The  product  model  and  IBES  model  knowledge 
bases  are  written  using  Rete++",  an  inference  engine  and  Windows  95™  C++  application 
programming  interface  that  extends  the  ‘C’  Language  Integrated  Production  System  (CLIPS). 

Figure  10  shows  the  logical  model  architecture.  To  expedite  implementation,  the  symbolic  model 
elements  (product  model  and  IBES  module)  use  blackboard  architecture  instead  of  inter-process 
communication.  Nonetheless  the  system  defines  and  invokes  each  module  (objects,  methods,  and 
rule  sets)  separately. 

The  CAD  subsystem  consists  of  AutoCAD®,  with  an  AutoCAD  ARX  customization.  The  ARX 
program  controls  the  programmatic  interface  to  the  CAD  system  and  communicates  with  the 
other  modules. 

The  analysis  application  for  the  control  valve  selection  problem  is  a small  program  that  takes  as 
input  the  validated  View  data  sent  by  the  broker  and  returns  a list  of  control  valves  by  computing 
the  minimum  and  maximum  coefficient  of  flow  and  looking  up  candidate  valves  in  a database. 
The  application  is  implemented  in  Java  and  resides  on  a server,  also  implemented  in  Java. 

Discussion 

This  paper  defines  a conceptual  framework  to  select,  extract,  validate,  and  communicate 
component  information  from  a product  model  for  an  engineering  analysis  application.  We  test 
the  hypothesis  that  these  services  can  be  abstracted  for  a general  approach  that  supports  the 
interoperation  of  Web-distributed  analysis  applications,  and  thus  improves  knowledge  sharing 
between  organizations.  Preliminary  evidence,  based  upon  a proof-of-concept  implementation  and 
a test  case,  suggests  that  a general  approach  is  possible. 

The  control  valve  problem  selected  for  the  test  case  addresses  component  configuration  for  the 
detailed  design  phase  of  a facility.  Clearly  more  work  is  required  to  extend  and  test  the  generality 
of  the  framework  for  a range  of  information  modeling  conditions  that  affect  view  generation  and 
match  against  application  input  specifications.  The  following  categories  highlight  potential  areas 
for  further  research: 


Model  query 

It  was  noted  that  the  interpretation  query  expressions  for  the  test  case  were  pre-defined.  It  was 
possible  to  pre-define  the  query  because  the  data  structures  for  the  product  model  were  static. 
This  simplifying  assumption  would  need  to  be  relaxed  for  a model  that  supports  schema 
evolution  for  which  it  would  be  necessary  to  construct  the  interpretation  query  dynamically. 
Furthermore,  the  IBES  architecture  currently  supports  the  formulation  of  data  views  that  abstract 
and  simplify  the  product  model  representation  for  an  engineering  analysis  application.  Other 
analysis  applications  require  model  elaboration  and  increased  representational  complexity,  or  the 
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translation  of  one  model  view  to  another  more  suited  to  a particular  analysis  requirement.  For 
example,  applications  for  cost  estimating  and  construction  planning  may  require  additional  data 
to  perform  reasoning.  Future  research  should  explore  formal  approaches  to  model  formulation24 
and  query  planning  for  model  query  and  interpretation. 


Incomplete  information 

The  incomplete  information  problem  poses  significant  database  design  issues.  A fully 
implemented  system  must  provide  a mechanism  to  add,  populate,  modify,  and  delete  schemata  in 
the  product  model  that  are  required  for  Product  Model  View  formulation.  In  addition  it  would 
need  to  manage  the  preservation  of  new  data  for  incomplete  or  partial  transactions  involving 
Product  Model  Views.  While  IBES  maintains  new  information  in  the  Product  Model  View,  it 
does  not  currently  address  dynamic  changes  to  the  underlying  product  model.  Other  research,  for 
example  EDM-29,  addresses  such  issues. 


Communication  language 

A standard  language  for  communication  between  software  objects  is  the  subject  of  considerable 
research  and  development.  The  Agent  Communication  Language  (ACL)  based  on  the 
Knowledge  Interchange  Format  (KIF)  vocabulary  fulfills  this  function.12  Similarly  the  emergent 
CORBA  standard  used  in  conjunction  with  the  proposed  extended  Markup  Language  (XML)  or 
an  equivalent  could  provide  these  services.15 


Conclusion 

Our  focus  on  modeling  engineering  content  in  support  of  specific  analysis  tasks  emphasizes 
practice-centric  rather  than  theoretic  engineering  research  methodology.  The  strength  of  this 
approach  is  that  it  positions  this  research  contribution  closer  to  the  problems  encountered  by  the 
AEC  industry. 

We  feel  the  practice-centric  approach  can  contribute  to  the  standardization  efforts  for  describing 
product  data.  By  formally  modeling  the  input  specifications  for  engineering  applications,  IBES 
establishes  a mechanism  to  test  whether  a product  model  schema  supports  the  reasoning  we  wish 
to  perform  with  the  model.  This  type  of  feedback  mechanism  is  critical  for  the  development  of  a 
modeling  testbed. 

We  have  attempted  to  bridge  the  methodological  gap  with  formal  theoretic  approaches  by 
founding  the  conceptual  model  for  IBES  on  established  knowledge  engineering  theory.  However 
we  recognize  and  have  noted  that  the  research  would  benefit  from  contributions  from  other 
domains. 
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To  bridge  our  work  with  industry  concerns  and  information  technology  strategies,  we  have 
positioned  the  research  to  address  the  critical  business  problem  of  sharing  knowledge  between 
information  publishers  and  subscribers.  We  have  also  conceptualized  the  IBES  integration 
services  as  middle-ware  that  could  be  implemented  in  an  interoperation  framework  such  as  the 
CORBA  standard  and/or  Microsoft  DCOM/ActiveX. 
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Figure  Captions: 

Figure  1:  Conceptual  IDEFO  Diagram  of  IBES  Integration  Activity. 

Figure  2:  IBES  intermediate  model  conceptual  framework  for  information  abstraction. 

Figure  3:  IDEFO  diagram  of  process  automation  tasks  supported  by  IBES. 

Figure  4:  Test  case  process  plant  sub-system,  represented  in  AutoCAD  as  a process  and 
instrumentation  diagram  (P&ID). 

Figure  5:  IBES  intermediate  model  objects 

Figure  6:  IBES  Map  relations  for  the  test  case. 

Figure  7:  IBES  component  service  manager  graphical  user  interface. 

Figure  8:  Conceptual  flow  diagram  of  data  validation  process. 

Figure  9:  IBES  prototype  logical  model. 
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Figure  1:  Conceptual  IDEFO  Diagram  of  IBES  Integration  Activity. 
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Figure  3:  IDEFO  diagram  of  process  automation  tasks  supported  by  IBES. 
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Figure  4:  Test  case  process  plant  sub-system,  represented  in  AutoCAD  as  a process  and 

instrumentation  diagram  (P&ID). 
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Figure  5:  IBES  intermediate  model  objects 
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Figure  6:  IBES  Map  relations  for  the  test  case. 
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Figure  7:  IBES  component  service  manager  graphical  user  interface. 
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Figure  8:  Conceptual  flow  diagram  of  data  validation  process. 
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Figure  9:  IBES  prototype  logical  model. 
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there  were  some  expressive  languages  and  related  computer  systems  which  were  good  at 
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representing  a very  broad  range  of  things,  like  the  natural  languages,  but  which  do  not  suffer 
the  problems  of  imprecision  and  ambiguity.  Database  systems  and  their  languages  (e.g.,  SQL, 
OQL)  offer  one  general  approach  and  certain  object-oriented  languages  perhaps  offer 
another.  However,  it  is  difficult  or  impossible  to  capture  all  kinds  of  information  and 
knowledge  in  most  of  these  general  languages. 

KIF  is  a particular  logic  language  and  was  proposed  by  the  KSE  as  a standard  to  describe 
things  within  computer  systems,  e.g.  expert  systems,  databases,  intelligent  agents,  knowledge 
bases,  etc.  Moreover,  it  was  specifically  designed  to  make  it  useful  as  an  "interlingua".  By  this 
we  mean  a language  which  is  useful  as  a mediator  in  the  translation  of  other  languages.  For 
example,  people  have  built  translation  programs  that  can  map  a STEP/PDES  expression 
into  an  equivalent  KJF  expression  and  vice  versa.  If  we  had  another  language  for  electronic 
commerce,  say  MSEC,  we  could  develop  a translator  to  and  from  KIF.  We  would  then  have 
a way  to  translate  between  STEP/PDES  and  MSEC  using  KIF  as  an  intermediate 
representation. 

So,  what  are  the  issues  regarding  translation  between  Jess  (or  CUPS)  and  KJF?  In  general, 
providing  a complete  translation  from  one  language  (Jess)  to  another  (KEF)  and  vice  versa  is 
a hard  or  even  intractable  problem  because  the  logics  expressed  by  the  two  languages  might 
not  be  equivalent.  The  experience  of  the  Stanford  researchers  involved  with  KIF,  suggests 
that  it  is  very  unlikely  for  one  to  get  a general-purpose  translator  from  KIF  into  CLIPS. 
Often  though,  for  practical  applications  we  do  not  need  a complete  translation;  translating  a 
sufficiently  expressive  subset  of  the  source  language  to  the  target  language,  could  be  enough 
for  many  knowledge  bases.  We  further  discuss  this  notion  of  a partial  translation  when 
discussing  Ontolingua.  We  are  not  aware  of  any  results  investigating  the  other  direction  of 
the  translation,  i.e,  from  CLIPS  (or  Jess)  into  KEF. 


Ontolingua 

The  question  of  the  meaning  of  the  terms  is  a more  difficult  one.  Knowledge  bases  are 
designed  with  a particular  view  of  the  world;  they  have  different  models  of  the  world  in 
which  objects,  classes  and  properties  of  objects  of  the  world  may  be  conceptualized 
differently.  For  example,  the  same  object  (in  the  real  world)  may  be  named  differently  or  the 
same  term  may  have  different  definitions.  In  addition,  knowledge  bases  may  conceptualize 
different  taxonomies  from  different  perspectives.  Therefore,  to  ensure  accurate  sharing  of 
knowledge  between  any  two  knowledge  bases  they  must  agree  on  the  model  of  the  world,  at 
least  the  part  of  the  world  about  which  they  are  exchanging  information  with  each  other,  or 
to  use  the  proper  terminology,  they  must  share  a common  ontology.  An  ontology  for  a 
domain  is  a conceptualization  of  the  world  (objects,  qualities,  distinctions  and  relationships, 
etc.  in  that  domain).  Such  a specification  should  be  an  objective  (i.e.,  interpretable  outside  of 
the  knowledge  base)  description  of  the  concepts  and  relationships  that  the  applications  use 
and  refer  to.  A shared  ontology  can  be  in  the  form  of  a document  or  a set  of  machine 
interpretable  specifications. 
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As  a concrete  representation  in  a computer,  an  ontology  consists  of  a specification  of 
concepts  to  be  used  for  expressing  knowledge  including  the  types  and  classes  of  entities,  the 
kinds  of  attributes  and  properties  they  can  have,  the  relationships  and  functions  they  can 
participate  in  and  constraints  that  hold  over  them.  Ontologies  are  distinguished  from 
knowledge-bases  in  general  not  by  their  form,  but  by  the  role  they  play  in  representing 
knowledge.  Ontologies  are  typically  consensus  models  for  a particular  domain.  They  place 
an  emphasis  on  properties  that  hold  in  all  situations  rather  than  on  one  or  more  particular 
ones.  Consequently,  their  implementations  put  an  emphasis  on  representing  generic  classes 
over  specific  instances.  Ontologies  do  not  tend  to  change  over  the  course  of  their  use  in 
problem  solving,  so  are  well  suited  to  compiling  into  programming  tools  and  environments. 
Since  ontologies  by  their  nature  need  to  support  and  satisfy  a community  of  users  (and 
developers)  there  is  a emphasis  on  collaborative  development  and  on  the  ability  to  translate 
them  into  multiple  representational  formalisms. 

Within  the  context  of  the  KSE,  researchers  at  Stanford’s  Knowledge  Systems  Laboratory 
have  developed  a set  of  tools  and  services  to  support  the  process  of  achieving  consensus  on 
common  shared  ontologies  by  geographically  distributed  groups.  These  tools  are  built 
around  Ontolingua,  a language  designed  for  describing  ontologies  with  it,  and  make  use  of 
the  world-wide  web  to  enable  wide  access  and  provide  users  with  the  ability  to  publish, 
browse,  create,  and  edit  ontologies  stored  on  an  ontology  server.  Users  can  quickly  assemble 
a new  ontology  from  a library  of  existing  modules,  extend  the  result  with  new  definitions 
and  constraints,  check  for  logical  consistency,  and  publish  the  result  back  to  the  library.  In 
addition,  the  KSL  Ontology  server  is  able  to  translate  Ontolingua  ontologies  into  a number 
of  other  representation  formalisms  such  as  LOOM,  CLASSIC,  KIF  and  CLIPS.  Actually, 
Ontolingua  has  two  different  translations  into  CLIPS;  translating  to  and  from  Ontolingua  is 
for  the  most  part  equivalent  to  translating  to  and  from  KIF  since  Ontolingua  is  designed  on 
top  of  KIF.  One  translation  tries  to  translate  into  the  OO  substrate  of  CLIPS;  this 
translation  is  not  too  good,  and  is  limited  largely  by  the  representational  inadequacies  of 
CLIPS's  OO  system.  The  other  translates  the  KIF  sentences  into  a direct  CLIPS  analogue 
of  the  KIF  sentences.  The  conclusion  is  that  neither  of  the  two  methods  provides  a 
foolproof  translation. 


Knowledge  Query  and  Manipulation  Language  (KQML) 

Besides  KIF  and  Ontolingua  there  was  a third  crucial  component  in  the  KSE  approach,  the 
KQML  language  (Knowledge  Query  and  Manipulation  Language).  KQML  is  a high-level 
language  and  protocol  for  applications  (such  as  knowledge  bases  or  information  agents)  that 
need  to  exchange  knowledge.  This  exchange  is  a level  above  the  process  of  transporting  bits 
and  bytes;  it  involves  higher-level  informational  attitudes  about  knowledge,  such  as  querying, 
informing,  expression  of  interest  in,  ability  to  deliver  information  about,  and  so  on.  The  idea 
was  for  KIF,  Ontolingua  and  KQML  to  be  used  in  unison:  the  represented  knowledge 
would  be  expressed  in  KIF  (or  translated  to  and  from  KIF),  the  various  terms  would  have 
meaning  captured  in  ontologies  defined  in  Ontolingua  and  KQML  would  provide  the 
higher-level  messaging  protocol  for  real-time  interaction  between  applications.  Of  course 


45 


KIF,  Ontolingua  and  KQML  can  be  used  independently  of  each  other  in  order  to  solve 
different  aspects  of  the  knowledge-sharing  problem.  So,  it  does  not  matter  to  KQML 
whether  applications  exchange  knowledge  represented  in  Jess  (or  pure  CLIPS  for  that 
matter)  or  KIF. 


Knowledge  Sharing  and  the  Web 

The  KSE  started  at  a time  when  the  WWW  was  not  a part  of  everyday  vocabulary.  An 
important  issue  is  how  to  make  use  of  these  languages  and  technologies  in  a web 
environment.  A recent  important  development  is  the  emergence  of  XML  (eXtended  Markup 
Language).  XML  is  an  SGML-type  language  and  format  that  is  often  promulgated  as  the 
successor  to  HTML.  Technically  speaking,  XML  itself  is  not  a single  markup  language  but  a 
metalanguage  that  lets  users  design  their  own  markup  language.  A regular  markup  language 
defines  a way  to  describe  information  in  a certain  class  of  documents  (e.g.  HTML).  XML  lets 
you  define  your  own  customized  markup  languages  for  many  classes  of  document.  Another 
effort  that  is  of  interest  is  RDF  (Resource  Definition  Framework).  RDF  is  designed  to 
provide  an  infrastructure  to  support  metadata  across  many  web-based  activities  and  is 
intended  to  provide  a uniform  and  interoperable  means  to  exchange  the  metadata  between 
programs  and  across  the  Web.  Furthermore,  RDF  will  provide  a means  for  publishing  both 
a human-readable  and  a machine-understandable  definition  of  the  property  set  itself.  RDF 
will  use  XML  as  the  transfer  syntax  in  order  to  leverage  other  tools  and  code  bases  being 
built  around  XML. 

XML  and  possibly  RDF  will  allow  for  ontology  definitions  that  are  instantly  web-ready  and 
web-accessible.  Does  this  make  Ontolingua  obsolete?  Ontolingua  is  an  entire  language  and 
set  of  tools  tailored  for  ontology  development;  what  will  probably  happen  (actually  Stanford 
KSL  researchers  are  already  exploring  this  direction)  is  a translation  of  Ontolingua 
specifications  into  XML.  This  would  make  XML  the  format  of  choice  for  encoding  and 
expressing  ontologies.  But  the  features  of  XML  offer  other  possibilities,  too:  the  authors  are 
currently  working  at  UMBC  on  XML  encodings  for  KIF  and  KQML  and  other  researchers 
are  experimenting  with  XML  encodings  of  Jess  rules.  The  ultimate  goal  is  to  use  XML  as  a 
universal  encoding  for  rules,  term  definitions  and  message  exchanges  and  to  remove  the 
barrier  of  what  the  human  user  understands  and  what  the  machine  interprets.  At  least  in 
theory,  XML  offers  the  promise  of  a continuum  where  knowledge  is  dynamically  captured 
and  accessed  by  both  human  and  machine. 

Conclusion 

Further  work  on  this  project  should  include  knowledge  sharing  as  a primary  goal.  It  should 
also  focus  on  XML  and  the  possibilities  it  offers  for  expressing  the  implicit  ontology  that  the 
knowledge  base  encompasses.  Also,  an  XML-encoding  of  KIF  rules  would  be  an  interesting 
way  to  represent  the  knowledge  captured  in  the  Jess  rules  themselves.  Given  the  lack  of  tools 
(and  experience)  for  translation  from  Jess  (or  CLIPS)  into  KIF,  we  would  rather  re-write  the 
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knowledge  base  in  KIF  than  attempt  to  translate  the  Jess  rules  into  KIF  rules.  A major 
problem  with  such  a re-write  would  be  the  graphical  interface  that  in  the  Jess  version  of  the 
system  is  defined  as  Jess  rules.  But  the  appeal  of  XML  is  that  it  would  allow  us  to  separate 
the  domain  knowledge  and  the  problem-solving  logic  (the  rules  that  actually  encode  the 
domain  knowledge)  from  the  presentation,  which  is  going  to  be  delivered  via  XML  and  a 
browser. 
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Knowledge  For  The  Coatings  Industry:  Needs  and  Progress 


Bernard  R.  Appleman 

The  Society  for  Protective  Coatings 


1.  Introduction 

Knowledge  and  Information  are  in  vogue  these  days.  We  are  said  to  be  in  the 
“information  age.”  For  example,  this  conference  is  about  knowledge  systems.  The 
Society  for  Protective  Coatings  (SSPC)  developed  a strategic  plan  in  1996.  One  of  the 
primary  goals  is  to  develop  a knowledge  center,  although,  it  has  not  yet  been  clearly 
defined.  It  is  important  to  determine  what  the  market  will  be  for  this  knowledge  based  on 
the  potential  uses  and  users. 

The  objectives  of  this  paper  are: 

□ To  describe  the  needs  of  the  industrial  coatings  industry  for  knowledge,  and 

□ To  describe  how  SSPC  and  others  are  working  to  fill  that  need. 

The  first  part  of  the  paper  addresses  the  following: 

□ Defining  the  coatings  industry  and  its  needs 

□ Examining  knowledge  components  for  the  coatings  industry 

□ Identifying  desired  capabilities  of  the  knowledge  delivery  system 

□ Comparing  knowledge  sources  versus  knowledge  needs. 

The  second  part  of  the  paper  reviews  the  following  programs  to  address  the  above  needs: 

□ Computer  compatible  data  formats  for  paint  data  sheets 

□ Expert  systems 

□ Websites 

□ Training  on  the  use  of  electronic  products  and  services. 

2.  Defining  the  Coatings  Industry  and  Its  Needs 

The  first  step  is  to  define  the  groups  who  will  benefit  by  coatings  knowledge,  these  are 
the  “customers.” 

A.  “Customers” 

In  the  coatings  industry,  SSPC  distinguishes  two  types  of  customer  groups. 
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□ Primary  customers  are  users,  specifiers  and  applicators  of  protective  coatings.  These 
are  the  organizations  with  a direct  responsibility  to  achieve  a successful  coatings 
project. 

□ Secondary  customers  are  organizations  that  provide  services  and  products  to  the 
primary  customers  (e.g.,  coating  materials,  application  equipment,  failure  analysis, 
waste  disposal). 

B.  Partners 

It  is  noted  that  coatings  are  not  a stand-alone  product.  They  serve  a function  by 
enhancing  the  value  of  other  engineering  and  construction  materials  and  processes.  This 
fact  highlights  the  need  for  the  coatings  industry  to  partner  with  other  groups  and 
associations  such  as: 

□ Those  who  represent  specific  industry  segments  such  as  bridge  (e.g.,  AASHTO)  and 
petrochemical  (e.g.,  API); 

□ Those  who  represent  segments  based  on  materials  of  construction  such  as  concrete 
(ACI)  or  steel  (AISC); 

□ Those  who  represent  segments  based  on  service  to  professionals  such  as  industrial 
hygienists  (AIHA),  specifiers  (CSI)  or  painting  contractors  (PDCA). 

C.  Customer  Needs 

The  next  step  is  to  identify  the  needs  of  the  customer.  For  this  paper  we  focus  on  the 
primary  customers.  Their  general  needs  of  the  owners  are: 

□ To  solve  problems; 

□ To  earn  or  save  money; 

□ To  protect  structures. 

Knowledge  is  of  interest  to  these  customers  because  it  can  help  customers  meet  these 
general  needs.  There  are  also  other  means  to  address  these  needs  (e.g.,  increased 
budgets,  or  higher  prices). 


3.  Knowledge  Components  for  the  Coatings  Industry 

This  section  discusses  knowledge  as  it  relates  specifically  to  the  coatings  industry  for  the 
primary  customers. 

A.  Types  of  Knowledge  Needed 

Some  examples  of  coating-related  activities  which  require  knowledge  are: 

□ Selecting  and  specifying  coating  systems; 

□ Tests  and  other  measures  to  ensure  performance; 

□ Tests  and  other  measures  to  ensure  conformance  with  standards  and  regulations; 
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□ Procedures  for  managing  coatings  programs; 

□ Evaluating  and  correcting  deficiencies  and  failures; 

□ Assessing  short  term  and  life  cycle  costs. 

B.  Examples  of  Components  of  Knowledge 

Recall  the  distinction  by  Richard  Wright  at  the  1996  CIKS  Workshop  on  data 
information  and  knowledge. 

□ Data:  basic  building  blocks  in  the  form  of  numbers,  words,  sounds,  and  images. 

□ Information:  data  that  has  been  arranged  into  meaningful  patterns  (e.g.,  database, 
plans,  specifications). 

□ Knowledge:  application  and  productive  use  of  information  (e.g.,  models,  expert 
systems). 

Examples  are  given  for  each  of  these  using  coatings  as  the  subject. 

□ Data:  (numbers,  descriptions,  images) 

□ Rust  spots  on  a bridge; 

□ Paint  film  thickness  recorded  in  numerous  locations; 

□ Surface  salts  observed  and  measured. 

□ Information:  (patterns  of  data) 

□ Rust  clustered  around  bridge  bearing  areas; 

□ High  salt  levels  measured  around  bearing  areas; 

□ Film  thickness  relatively  uniform  over  entire  bridge  surface. 

□ Knowledge:  (application  and  productive  use  of  information) 

□ Early  rusting  was  caused  by  failure  to  remove  salt  and  not  by  improper  film 
thickness. 

C.  Additional  Knowledge  Concepts 

□ Wisdom 

th 

Daniel  Burrus,  a self-styled  “futurist”  suggests  adding  wisdom  as  a 4 tier  beyond 
knowledge.  He  defines  it  as  “universal  truth  that  enriches  and  enhances  life.” 

Possible  examples  of  wisdom  based  on  the  previous  analysis  are: 

□ Remove  salt  to  a designated  level  (e.g.,  10  micrograms  per  sq  cm)  before 
painting; 

□ Use  a coating  which  can  tolerate  salt. 

□ Sharing  of  knowledge 

Burrus  also  emphasizes  the  need  to  share  knowledge  to  achieve  wisdom.  An  example 
is  as  follows: 

□ User  A has  knowledge  of  coatings.  A,  B,  C in  exposure  X over  salt  level  Y for  48 
months. 

□ Supplier  B has  knowledge  of  the  ability  of  methods  A,  B,  C,  D to  remove  salt 
prior  to  painting. 
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Sharing  such  knowledge  could  produce  a knowledge  base  of  the  performance  of 
different  paints  over  various  salt  levels  in  various  exposures.  This  shared  knowledge 
would  lead  to  more  informed  decision  making. 


4.  Desired  Capabilities  of  a Knowledge  Delivery  System 

A.  General 

So  far,  we  have  discussed  the  need  for  knowledge  (including  information  and  data)  by  the 
coatings  industry.  The  next  issue  is  how  can  this  knowledge  be  imparted  to  these 
individuals  to  meet  the  primary  goals  (i.e.,  protect  structures,  save  money,  solve 
problems.).  What  is  needed  is  a knowledge  delivery  system.  A discussion  of  how  the 
knowledge  will  be  acquired  and  delivered  is,  to  a large  extent,  the  focus  of  this 
conference  as  a whole  and  beyond  the  scope  of  this  paper.  It  is,  however,  useful  to 
identify  what  the  user  desires  from  such  a system.  Later,  we  will  compare  current 
mechanisms  against  these  derived  attributes. 

B.  Acquisition 

One  cannot  use  knowledge  unless  it  exists  and  is  available,  so  perhaps  the  first  step  is  to 
acquire  the  knowledge.  Obviously,  for  the  knowledge  to  be  most  useful,  it  would  need  to 
be  comprehensive  in  scope,  subject  matter  and  depth  with  continual  updating. 

C.  Accessibility 

The  user  will  not  benefit  if  there  is  an  enormous  comprehensive  up-to-date  body  of 
knowledge  if  that  knowledge  is  not  accessible  to  that  user.  Important  factors  affecting 
accessibility  include  the  complexity  and  cost  of  the  hardware  and  software,  the  level  of 
expertise  to  operate,  and  the  speed  and  ease  of  access.  Again,  many  of  these  items  will 
be  discussed  at  this  conference. 

D.  Validation 

An  important  concern  is  the  validity  and  credibility  of  knowledge  from  divergent  sources. 
For  example,  a supplier’s  “knowledge”  may  be  biased  by  his  desire  to  promote  his  own 
product.  The  facility  owner  may  not  be  knowledgeable  in  what  constitutes  good 
performance  (e.g.,  by  not  recognizing  the  need  to  inspect  in  certain  critical  locations). 

In  the  past,  the  development  of  consensus  standards  and  reports  and  peer-reviewed  papers 
helped  provide  a degree  of  credibility.  In  the  electronic  age  new  approaches  are  needed 
because  information  is  often  transmitted  without  such  “filters.” 

The  user  also  needs  evidence  of  the  process  used  to  validate  the  knowledge.  This  could 
consist  of  a “good  housekeeping  seal  of  approval”  by  a recognized  professional  body  or 
by  a “paper”  trail  of  how  and  by  whom  the  review  and  validation  were  conducted. 
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E.  Consolidation 

Another  concern  is  the  vast,  often  intimidating  quantity  of  information  and  knowledge 
available.  The  primary  customers  who  use  the  technology  are  able  to  devote  less  and  less 
time  to  acquiring,  and  evaluating  knowledge.  The  demands  of  the  job  are  being  stretched 
thinner  and  thinner.  There  are  less  time  and  funds  available  for  testing  or  evaluating 
candidate  coatings  in  specific  exposures.  The  users  are  seeking  immediate  answers. 

They  often  appear  less  concerned  with  the  quality  of  the  answer  than  with  their 
timeliness.  There  is  greater  reliance  on  suppliers  and  contractors  to  make  decisions  that 
had  been  previously  made  by  in-house  materials,  corrosion,  and  coatings  specialists. 

F.  Cost 

The  customer  wants  to  pay  as  little  as  possible  (at  least  in  direct  costs)  for  the  knowledge. 
In  some  cases,  engineering  firms  and  contractors  are  hired  to  undertake  major  portions  of 
the  engineering  and  construction.  However,  within  these  firms  there  often  is  little 
expertise  or  experience  in  coatings  technology  and  an  unwillingness  to  expend  resources 
to  acquire  this  knowledge.  Coatings  are  considered  a minor  part  of  the  project,  like  the 
color  for  your  house.  These  owners  and  their  consultants  often  do  not  recognize  the 
overall  value  of  coatings.  In  addition,  those  who  regularly  use  the  Internet  are 
accustomed  to  a lot  of  knowledge  and  information  without  paying  for  it. 

G.  Summary  of  Desired  Capabilities  of  Knowledge  Delivery  System 

The  customers,  therefore,  have  the  following  needs  with  regard  to  coatings  knowledge: 

□ Availability  of  comprehensive  base  of  knowledge  to  solve  problems 

□ Quick  access  to  knowledge 

□ Validated  knowledge 

□ Consolidated  knowledge  which  is  easy  to  understand/apply 

□ Inexpensive  process 

Inevitably,  in  a wish  list  such  as  this  there  are  inconsistencies  and  contradictions. 

5.  Comparing  Knowledge  Sources  Versus  Knowledge  Needs 

In  this  section,  we  identify  the  most  common  sources  of  knowledge  for  coatings  users 
and  compare  them  against  the  attributes  identified  previously. 

A.  Sources  of  Knowledge 

We  divide  the  sources  into  non-electronic  and  electronic. 

□ Non-electronic 

□ Hire  a paid  consultant 

□ Contact  a supplier  (non-paid) 

□ Contact  a colleague  (visit,  letter,  fax,  phone) 

□ Read  technical  literature  (books,  periodicals,  standards) 

□ Attend  training  or  conferences 
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□ Computer  sources 

□ Use  CD-Roms  containing  searchable  knowledge  base 

□ Use  expert  system  on-line 

□ Access  chat  rooms  or  on-line  forums 

□ Send  email  to  colleagues,  suppliers 

□ Send  email  to  consultant  who  provides  on-line  services 

□ Access  a searchable  on-line  database 

B.  Ranking  Different  Types  of  Knowledge  for  Desired  Attributes 

Table  1 ranks  the  various  sources  listed  above  based  on  the  desired  attributes  identified 

previously.  Rating  are  1 to  5,  where  5 is  best.  These  are  discussed  below. 


Able  to 
acquire 
knowledge 

Able  to 
validate 
knowledge 

Provide 
quick  access 

Inexpensive 

Easy  to 
understand/ 
apply 

Paid 

consultant 

3 

3-4 

4 

2 

5 

Supplier 

3 

1 

3 

5 

5 

Colleague 

2 

2 

2 

5 

5 

Reference 

books 

4 

3-4 

2 

3 

2 

Conference 

s/training 

3 

3-4 

1 

2 

3 

CD-Rom 

5 

3 

4 

3 

2 

Expert 

system 

3 

4 

2 

2 

4 

Chat 

room/forum 

1-2 

1 

3-4 

5 

3 

On-line 
data  base 

5 

3 

5 

1-2 

2 

E-mail 

colleagues 

1-2 

2 

2 

5 

2-3 

E-mail 

consultants 

2 

3-4 

4 

3 

4 

Table  1:  Rankings  for  various  knowledge  sources  . 

□ Adequacy  of  sources  in  acquiring  knowledge  - The  Electronic  products  (on-line  and 
CD-ROM  databases)  furnish  the  greatest  quantity  of  information  potentially.  Of  the 
non-electronic  sources,  the  conventional  media  of  standards,  books,  and  journals  also 
provide,  collectively,  a large  body  of  data. 
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□ Adequacy  of  sources  in  validating  knowledge  - An  expert  system  if  designed 
properly  can  furnish  reliable  validated  data  and  information.  The  information  from  a 
paid  consultant  should  be  reliable  if  the  consultant  is  competent.  Standards  provide 
valid  data  as  do  information  derived  from  training.  Information  derived  from 
colleagues,  suppliers  or  from  chat  rooms  tend  to  be  based  on  personal  experience  and 
do  not  necessarily  represent  a balanced  perspective. 

□ Adequacy  of  sources  in  providing  quick  access  On-line  databases  and  CD-ROMs  can 
provide  extremely  rapid  access  if  the  user  is  knowledgeable  in  these  applications. 
Consultants,  when  pressured,  can  provide  relatively  quick  access  if  they  have  the 
right  tools  and  expertise.  Other  conventional  methods  (e.g.,  books  and  journals)  can 
provide  quick  access  if  one  is  very  proficient,  but  otherwise  can  be  very  time 
consuming.  For  courses  and  conferences  the  timing  is  based  on  the  offerer’s  needs 
and  not  the  user,  so  they  rate  low  in  this  category. 

□ Adequacy  of  sources  for  minimizing  expense  - Information  from  suppliers  and 
colleagues  is  often  given  free  as  is  access  to  chat  rooms.  On-line  databases  and  CD- 
ROMs  may  require  relatively  high  investments  in  equipment  along  with  service 
charges.  Books  and  other  hard  copy  reference  materials  are  relatively  inexpensive 
individually,  but  collectively  can  add  up  to  a sizeable  investment.  Consultants 
typically  charge  for  their  services,  but  for  relatively  easy  questions,  these  may  be 
provided  without  charge. 

□ Adequacy  of  sources  in  providing  information  that  is  easy  to  understand  and  apply  - 

The  responses  of  consultants,  colleagues  and  suppliers  are  typically  the  easiest  to 
understand  and  apply,  because  they  are  acquired  from  an  individual  from  direct 
conversation.  On-line  databases  and  CD-ROMs  are  often  the  least  user  friendly 
because  the  user  is  limited  by  the  sophistication  of  the  database  engine  and  the  way  it 
has  been  constructed.  Expert  systems  are  often  designed  to  give  pragmatic  answers 
(i.e.,  knowledge  rather  than  information  or  data).  This  depends  significantly  on  the 
quality  of  the  expert  system. 

C.  Discussion  of  Rankings 

□ Analysis  of  rankings  - It  is  clear  that  no  single  source  meets  all  the  stated  user  needs. 
Overall,  the  electronic  products  have  high  rankings  in  access  to  knowledge,  and  the 
comprehensiveness  of  the  knowledge.  The  validation  of  the  data  may  be  difficult  and 
the  data  may  be  of  limited  use  for  direct  application  to  a field  problem.  Finally,  the 
cost  may  be  relatively  high.  The  conventional  (non-computer)  sources  as  a rule  are 
relatively  easy  to  use.  A large  quantity  of  data  is  typically  available,  but  it  may  not  be 
as  readily  retrievable  to  a novice  and  there  are  often  contradictory  and  inconsistent 
treatments  of  technology  among  the  diverse  sources  when  validated  data  (e.g., 
standards,  training  programs)  are  available.  Direct  costs  for  acquiring  this 
information  may  be  low,  but  the  time  involved  can  significantly  increase  the  cost  to 
the  customer. 

□ Guidance  in  developing  electronic  products  - In  some  instances,  it  is  necessary  to 
develop  products  or  protocols  that  will  not  be  useful  or  available  to  more  than  a small 
fraction  of  the  user  community  for  one  or  more  years.  It  is  important,  however,  to 
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recognize  this  up  front.  Otherwise,  the  supplier  of  electronic  products  may  run  out  of 
resources  because  the  return  is  not  what  was  anticipated.  A risk  in  over  zealous 
marketing  of  computer  products  is  that  the  user  may  become  frustrated  or  discouraged 
because  the  “hype”  has  not  been  delivered.  The  user  may  then  find  other  sources  or 
may  be  content  to  make  decisions  without  the  best  knowledge.  This  latter  could  hurt 
the  entire  industry,  resulting  in  loss  of  market  to  other  technologies  or  to  overseas 
competition.  Overall,  it  is  necessary  to  focus  on  the  areas  where  the  electronic-based 
sources  have  strengths  and  to  recognize  the  deficiencies. 

6.  Current  Programs  Addressing  Knowledge  Needs 

The  SSPC  currently  has  several  programs  focused  on  development  and  transmitting  of 
knowledge  through  electronic  means. 

□ Computer  compatible  data  format  and  paint  data  sheet 

□ Expert  systems  on  protective  coatings 

□ Websites 

□ Training  on  use  of  electronic  products  and  services 

A.  Format  for  Paint  Data  Sheet 

An  SSPC  committee  has  developed  a proposed  format  for  industrial  paint  technical  data 
sheets.  These  data  sheets  are  used  by  paint  manufacturers  to  describe  technical  properties 
of  coating  materials  including  application  instruction,  physical  properties,  and 
performance  properties.  There  is  no  standard  format  in  use  by  the  industry.  Each 
manufacturer  tends  to  emphasize  different  features,  sometimes  depending  on  the 
coating’s  strength  and  the  perceived  needs  for  user  information.  In  addition,  the 
documents  have  been  developed  for  hard  copy  distribution,  so  their  adaptability  to 
computer  formats  is  inconsistent. 

The  Task  Group  developed  a document  which  addresses  the  above  deficiencies.  It 
includes  sections  on  mandatory  data  (required  of  all  producers)  and  supplementary  data 
(optional).  The  major  categories  are:  product  description;  intended  use;  physical 
properties;  mixing  and  application;  and  key  performance  parameters  (including  test 
methods  and  results). 

The  draft  standard  has  been  posted  at  the  NIST  list  server  and  Web  site  and  made 
available  electronically  to  the  Task  Group.  A revised  draft  was  sent  to  a larger  group 
(SSPC  Unit  Committee)  electronically  as  well  as  by  hard  copies  for  the  committee  ballot. 

B.  Expert  Systems 

An  additional  project  of  the  CIKS  - SSPC  Task  Group  was  to  identify  and  characterize 
expert  systems  of  coatings  knowledge.  Expert  systems  are  available  for  the  following 
applications: 


55 


□ Maintenance  painting  planning  - Programs  allow  a user  to  follow  a defined  procedure 
to  assess  the  condition  of  coatings  on  a structure.  This  is  based  on  a systematic 
inspection  and  rating  of  various  structure  elements  at  a facility.  The  condition  is  rated 
on  a scale  of  1 to  7 or  1 to  10,  based  on  previously  determined  criteria  (e.g.,  percent 
of  rust  or  percent  of  paint  breakdown). 

□ Life-cycle  cost  analysis  - With  these  systems,  the  user  is  able  to  determine  the  cost  of 
one  or  more  coating  systems  over  a period  of  years.  The  input  to  the  model  consists 
of  costs  incurred  at  various  times  due  to  initial  painting,  maintenance  painting,  minor 
touchup  or  steel  repair.  The  cost  of  these  activities  is  derived  from  estimates  of  the 
cost  of  labor  and  materials.  The  intervals  between  painting  are  a more  subjective 
area.  These  are  based  on  charts  and  other  data  on  coating  lifetimes  and  degradation 
rates.  The  level  of  surface  preparation,  the  type  or  thickness  of  the  paint  and  the 
severity  of  the  exposure  environment  influence  these  lifetimes. 

□ Failure  analysis  - Expert  systems  are  also  being  developed  to  guide  the  user  in 
analyzing  coating  failures.  The  users  are  asked  a series  of  questions  to  help  describe 
the  failure  by  comparison  to  photographic  or  written  descriptions.  The  user  is  pointed 
to  one  or  more  probable  causes  and  advised  on  means  to  determine  the  specific  cause 
and  appropriate  remedy. 

□ Selecting  a specification  - Under  this  system,  the  user  is  asked  to  select  parameters 
for  products  and  specifications  for  a painting  project.  The  user  is  asked  questions 
about  the  type  of  substrate,  the  type  of  exposure,  restrictions  on  surface  preparation, 
esthetics  (e.g.,  gloss,  color)  other  performance  requirements,  limitations  on  volatile 
organic  compound  (VOC)  content,  other  performance  parameters  and  the  anticipated 
design  life  of  the  structure.  The  expert  system  can  be  limited  to  the  products  of  a 
single  manufacturer  or  directed  to  include  multiple  manufacturers.  The  expert  system 
then  can  produce  a complete  specification  which  can  be  used  to  procure  a contract  for 
applying  the  coating  system  selected.  Input  from  coating  manufacturers  is  needed  to 
furnish  specific  application  instructions  for  the  proprietary  materials  specified  and  to 
verify  that  these  products  meet  the  identified  performance  requirements. 

C.  Websites 

In  the  coatings  area  as  in  other  technologies,  websites  of  all  kinds  are  proliferating. 

SSPC  and  Technology  Publishing  Company  (TPC)  have  agreed  to  actively  develop  two 
complementary  websites.  The  TPC  side  includes  current  technical  articles  from  coatings 
journal  and  news  stories  as  well  as  substantial  information  on  products.  SSPC’s  site 
includes  frequent  updates  on  regulatory  information,  data  on  research  projects  and 
information  and  standards.  Both  sites  include  industry  forums  for  presenting  and 
responding  to  questions.  In  addition,  these  sites  identify  other  sites  for  linking  to  more 
specialized  information  on  regulations,  products  and  services  and  technology. 

D.  Training 

The  SSPC  committee  on  coatings  knowledge  recognizes  the  need  for  training  and 
orienting  novices  as  well  as  regular  Internet  users.  A few  brief  articles  have  been 
published  in  the  Journal  of  Protective  Coatings  and  Linings  (hard  copy  for  the  non-web 
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literate).  In  addition,  tutorials  have  been  developed  for  onsite  training  for  introductory 
and  advanced  students  on  the  subject  of  electronic  information  on  coatings. 

7.  Conclusions 

The  SSPC  Board  of  Governors  has  recognized  that  coatings  are  materials  that  are  part  of 
the  construction  engineering  industry  and  not  a stand-alone  product.  An  important  goal 
of  the  SSPC’s  Strategic  Plan  is  to  establish  a knowledge  center  that  is  strongly  linked  to 
other  groups  in  the  construction  engineering  community  (as  represented  by 
CONMAT/CERF).  SSPC  does  not  have  the  resources  or  time  to  develop  these  ideas  or 
practices  by  itself.  We  believe  we  can  best  serve  our  members  by  participating  in  forums 
such  as  these,  and  in  building  our  knowledge  center  on  the  foundation  of  previous 
experiences. 
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Computer  Integrated  Knowledge  Systems:  Proposed  Framework 


Thomas  Y.  Kurihara 
National  Institute  of  Standards  and  Technology 
Building  and  Fire  Research  Laboratory 


1.  Introduction 

The  construction  community  is  represented  by  a diverse  set  of  private  and  public 
organizations  and  disciplines.  The  industry  lacks  consistency  in  the  way  it  represents, 
communicates,  and  interprets  information  about  its  products,  materials,  and  systems. 
There  is  a need  to  establish  a framework  that  will  improve  the  service-life  and  durability 
of  structures  and  components,  and  reduce  costs  associated  with  construction,  operations, 
and  maintenance  activities.  Industry-scale  improvements  can  result  from  the  adoption 
and  implementation  of  a framework  that  includes: 

• consistent  terms  for  use  by  construction  industry  knowledge  users; 

• criteria  and  standards  for  data  quality  and  formats; 

• a standard  format  for  knowledge  interchange; 

• improved  methods  for  seeking  and  interpreting  knowledge; 

• an  intelligent  interface  for  users. 

This  paper  outlines  a proposed  framework  to  address  the  needs  of  the  construction 
industry  product,  materials,  and  systems  knowledge  users  involved  in  operation  and 
maintenance  activities,  such  as  condition  assessment,  material  failure  analysis,  and 
material  selection.  This  paper  is  an  abbreviated  version  of  the  NIST  Internal  Report 
(NISTIR-6071),  which  was  provided  to  all  of  the  workshop  attendees  and  was  the  basis 
for  the  presentation  of  the  CIKS  framework. 

CIKS  is  intended  to  be  used  for  constructed  facilities,  such  as  bridges,  private  and  public 
buildings,  etc.  Initially,  the  framework  addresses  the  industrial  coating  material  area. 
However,  the  activities  and  methodologies  described  will  apply  to  other  construction 
materials,  such  as  cementitious  materials,  steel,  aluminum,  composites,  and  roofing. 

Several  goals  have  been  established  for  the  implementation  of  CIKS.  These  goals 
provide  a context  for  its  development,  a long-term  vision,  and  near-term  usefulness.  It  is 
envisioned  that  refinements  to  the  framework  will  occur  as  user  needs  change  and  are 
better  understood  by  the  CIKS  developers  and  partners,  and  as  enabling  information 
technologies  emerge  over  the  5-year  development  life  of  CIKS.  CIKS  will  show  concept 
and  provide  value  within  a two-year  time  frame,  yet  maintain  a five-year  development 
life.  This  will  be  achieved  through  the  establishment  of  NIST/construction  industry 
partnerships  and  the  establishment  of  a test  bed  whereby  partners  can  test  production 
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systems  and  data  for  interoperability,  and  obtain  developmental  and  implementation 
solutions  for  incorporation  into  industry-developed  systems. 


2.  Goals  ofCIKS 

• Universal  exchange  of  knowledge 

One  goal  is  to  help  the  construction  industry  share,  exchange,  and  manage  knowledge 
through  a neutral  knowledge  interchange  format.  A major  focus  will  involve  document- 
based  knowledge  sources  such  as  handbooks,  guides,  standards,  and  dictionaries.  These 
documents  provide  a clear  reference  to  knowledge  sources  that  have  been  refereed  by 
industry  leaders.  Examples  of  these  include  the  American  Society  for  Testing  and 
Materials  (ASTM),  the  Society  for  Protective  Coatings  (SSPC),  and  the  American 
Concrete  Institute  (ACI).  Use  of  guides  developed  by  the  public  sector  will  result  in  the 
creation  of  digital  libraries,  and  decision-support  aids  (e.g.,  expert  systems)  that  will  be 
available  to  knowledge  users,  such  as  practicing  engineers.  Commercial  guides  will  be 
incorporated  into  the  CIKS  framework  by:  1)  an  interpretation  of  the  guides  (contained 
within  an  expert  system)  to  aid  in  engineering  practice,  and  2)  the  application  of 
electronic  commerce,  permitting  the  sale  of  documents  in  electronic  form. 

• Commercial  development  and  implementation  tools 

An  evaluation  of  commercial  products  and  information  technology  research  will  be 
conducted  with  an  emphasis  on  reusability.  This  will  accelerate  the  development  process 
and  reduce  the  level  of  effort  needed  to  implement  CIKS.  The  intention  is  not  to  conduct 
new  research,  but  to  integrate  or  ‘glue’  existing  information  technologies  and  research 
results  into  a functional  framework.  If  voids  exist,  then  the  value  of  building  or 
researching  those  missing  links  will  be  considered. 

• Development  and  implementation  partnerships 

Private  and  public  knowledge  centers  and  digital  information  networks  with  specific 
focus  areas  (e.g.,  coating,  high-performance  concrete)  hosting  their  knowledge  repository 
will  serve  as  examples  of  the  CIKS  framework.  Industry  leaders  will  collaborate  as 
partners  to  establish  and  host  knowledge  bases,  identify  user  requirements,  and  provide 
reusable  research  results.  One  factor  involved  in  the  success  of  CIKS  will  be  industry's 
interest  and  ability  to  adopt  CIKS  strategies  and,  in  some  cases,  reengineer  their  business 
process.  User  demands  for  value  added  knowledge  in  digital  form  will  serve  as  a driver 
for  product  and  material  manufacturers  and  information  brokers  to  maintain  a 
competitive  advantage.  Upon  completion,  the  various  stages  for  implementing  the  CIKS 
framework  will  be  submitted  to  a standards  setting  body  for  standardization.  Two 
scenarios  can  be  presented  for  possible  standardization:  1)  a U.S.  national  body  such  as 
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ASTM,  or  2)  a domain  specific  body  such  as  The  Society  for  Protective  Coatings  for  the 
coating  industry  or  the  American  Concrete  Institute  for  cementitious  materials.  The 
standardized  framework  would  establish  standards  and  guidance  on  terminology,  data 
formats,  and  models  for  representing  processes  (e.g.,  condition  assessment,  and  material 
selection  procedures)  in  decision-support  systems. 
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Figure  1 


3.  CIKS  Proposed  Framework 

Figure  1 shows  the  different  views  and  their  respective  parts.  The  proposed  framework 
contains  the  external,  management,  and  operational  views.  The  external  view,  includes 
the  partners,  user  interface,  and  network.  Partners  are  the  organizations  or  knowledge 
centers  with  whom  we  will  collaborate.  The  computer  user  interface  is  how  users  would 
access  the  data  and  knowledge.  The  network  is  the  digital  communication  infrastructure 
that  enables  users  to  connect  to  knowledge  bases  hosted  at  the  knowledge  centers. 

The  management  view,  describes  the  application,  data,  and  knowledge  management.  The 
application  management  area  addresses  user  applications  that  help  the  user  improve  the 
performance  of  knowledge  work  using  commercial  products,  and  research  applications 
focusing  on  agent  and  knowledge  acquisition  technology.  The  data  management  area 
addresses  standards,  data  elements,  models  and  tools.  The  knowledge  management  area 
focuses  on  terminology,  document  and  knowledge  exchange  technology.  The  knowledge 
exchange  approach  will  include  evaluating  the  Defense  Advanced  Research  Program 
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Agency  (DARPA)  Knowledge  Sharing  infrastructure  as  a practical  option.  The 
operational  view,  describes  a pilot  system,  options  that  need  to  be  considered,  the 
different  development  phases,  and  outlines  the  steps  for  building  an  example  of  the 
framework. 

The  foundation  of  the  framework  is  built  on  the  conceptual  representation  which  includes 
dictionaries,  a lexical  semantic  model  (a  model  of  the  relationships  contained  in  the 
dictionary),  standard  terms,  data  elements,  data  models,  document  models,  and 
knowledge  models.  (The  square  shapes  in  figure  1 refer  to  formal  or  engineered  items 
and  the  curved  shapes  refer  to  natural  or  human  aspects.) 


Figure  2 


Figure  2 shows  that  dictionaries,  thesauruses,  and  corpora  or  machine-readable  text  are 
the  inputs  to  creating  the  lexical  semantic  model,  a foundation  of  the  framework.  This 
figure  also  shows  the  relationship  of  the  lexical  semantic  model  to  the  implementation  of 
data,  document,  and  knowledge  exchange  mechanisms  (through  standard  models)  and  its 
role  as  the  foundation  upon  which  all  of  the  other  models  are  built.  The  current  exchange 
models  provide  only  a syntactical  exchange  mechanism,  while  the  lexical  semantic  model 
provides  the  foundation  for  a much  more  powerful  semantic  exchange  mechanism. 
However,  the  intention  is  not  to  conduct  natural  language  research,  but  to  incorporate  the 
research  results  into  a functional  framework. 
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Table  1 shows  how  the  proposed  CIKS  framework  could  be  implemented  while  the 
column  headings  of  crawl,  walk,  and  run  identify  the  different  development  phases  to 
represent  a progression.  The  rows  identify  the  type  of  research  applications,  user 
applications,  data,  documents,  terminology,  and  knowledge  management  components  that 
would  be  developed  and  made  available  through  a pilot  system. 


Headings 

Crawl  Phase 

Walk  Phase 

Run  Phase 

Research 

Applications 

• 

• Software  Agents 

• Automated 
Knowledge 
Acquisition 

• Intelligent  Agents 

User  Support 

Applications 

■ ■ 

• Information  Retrieval 

• Collaborative 
Environment 

• Decision  Support 

• Computer-based 
training 

• Expert  Systems 

Data 

• Web-enabled  database 

• Standard  metadata 

• A few  standard  data 
elements 

• Many  standard  data 
elements 

• Simple  standard  data 
models 

• Complex  data 
models 

• Complex  standard 
data  models 

Documents 

• Web-enabled  document 
management  system  (or 
system  of  systems) 

• Simple  Standard 
Document  Models 
(DTDs) 

• Complex  standard 
document  models 

Terminology 

• Standard  terminology 

• Adapt  existing  lexical 
models 

• Existing  standard 
concepts 

• Thesaurus 

• Align  differences  in 
selected  lexical 
models 

• Standard  lexical 
model  or  ontology 

Knowledge 

• Standard 
knowledge  model 

• Knowledge  base 

Table  1 : Development  Phases 


An  abbreviated  “crawl”  phase  example  could  include  determining  the  remaining  service- 
life  of  a coating,  performing  coating  failure  analysis,  and  then  identifying  the  optimal 
corrective  response.  The  optimal  response  will  be  based  on  life  cycle  costing  and  could 
include  doing  nothing,  providing  in-house  or  an  out-sourced  repair,  or  an  in-house  or  out- 
sourced replacement  action.  This  example  could  initially  proceed  as  described  below: 
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1 . The  first  step  is  to  identify  coating  dictionaries  as  the  standard  for  the  terminology 
that  is  used  in  the  specific  application  area.  If  a coatings  dictionary  does  not  exist, 
one  could  be  developed  (though  this  could  be  very  time  consuming). 

2.  The  next  step  is  to  begin  collecting  machine-readable  documents  that  address  the  area 
of  interest.  The  subjects  for  this  example  would  include  how  to:  assess  the  condition 
of  a coating,  perform  failure  analysis,  and  make  economic  decisions  when  the 
existing  coating  system  must  be  repaired  or  replaced. 

3.  In  parallel,  decisions  about  how  all  of  these  documents  will  be  managed  (e.g.,  using  a 
file  system,  an  existing  database,  or  a dedicated  document  management  system)  must 
be  made  and  implemented.  This  would  include  selecting  the  web-enabled  database 
and  document  management  system  that  will  be  used.  If  it  is  not  possible  to  select  a 
single  system  or  type  of  system  for  managing  all  documents,  then  it  will  be  necessary 
to  develop  specialized  interfaces  between  different  systems. 

4.  All  documents  should  be  contained  within  the  document  management  system  (or 
system  of  systems)  and  in  a format  that  permits  searches  using  information  retrieval 
technology.  This  would  be  the  beginning  of  a digital  library  of  relevant  engineering 
knowledge  or  know-how  documents  concerning  condition  assessment,  failure 
analysis,  and  economic  decisions. 

5.  The  next  step  requires  reviewing  metadata  (data  about  data)  standards  and  deciding 
which  standards  will  be  adopted. 

6.  After  that  step,  identifying  a few  standard  data  elements  is  similar  to  agreeing  on 
terminology,  but  within  the  database  context. 

7.  Finally,  assuming  that  how-to  or  knowledge  documents  are  created  by  the 
organization,  a collaborative  environment  should  be  defined  and  implemented,  which 
could  be  as  simple  as  using  email,  some  workflow  package,  or  selecting  a web-based 
collaborative  document  editing  environment. 

Managing  an  organization’s  knowledge  requires  a major  effort  from  the  basic  methods 
used  by  libraries  (as  the  original  knowledge  repository)  to  the  development  of  a 
knowledge  management  framework.  This  framework  provides  a phased  approach  for  an 
evolutionary  process,  from  developing  a digital  document  library  to  completing  an  agent- 
enabled  distributed  knowledge  base.  An  indicator  of  the  success  of  this  framework  will 
be  its  adoption  by  construction  materials  organizations  that  will  test  the  framework  in  the 
conduct  of  their  business  or  practice.  Finally,  the  framework  will  continually  evolve  and 
improve  as  new  research  is  made  available.  For  additional  details  refer  to  the  NIST 
Internal  Report  (NISTIR-6071)  titled  Computer  Integrated  Knowledge  Systems  (CIKS) 
for  Construction  Materials,  Components,  and  Systems:  Proposed  Framework. 
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Construction  Supernetwork 


Alan  Sparkman 

Aberdeen  Group,  Electronic  Media  Division 

The  Construction  Supemetwork  is  an  Internet-based  medium  for  addressing  the  needs  of 
construction  industry  users.  Currently,  the  network  is  an  integral  part  of  the  Aberdeen 
Group  World  of  Concrete  website  and  addresses  the  areas  of  concrete  and  masonry 
materials  and  construction.  Specific  topics  include  magazine  archives,  problem  clinic, 
buyers  guide,  online  magazines,  and  an  on-line  bookstore.  At  the  time  of  this  workshop 
the  Construction  Supemetwork  had  entered  into  a joint  venture  with  the  American 
Concrete  Institute  (ACI)  to  produce  a website  for  the  ACI  constituency.  The  categories 
of  information  related  to  ACI  activities  included: 

□ Goals  and  services 

□ Technical  committee  activities  and  membership 

□ Publications  and  electronic  products. 

The  Aberdeen  Group  through  its  Construction  Supemetwork  was  commissioned  by  ACI 
to  develop  an  e-commerce  presence  for  ACI.  During  1998,  the  Constmction 
Supemetwork  was  sold  to  another  publisher  and  ACI  began  hosting  and  developing  its 
own  website  through  the  Institute  staff. 

Information  regarding  the  Constmction  Supemetwork  can  be  found  online  by  pointing  a 
web  browser  to:  www.worldofconcrete.com 

The  ACI  website  is  accessible  by  pointing  a web  browser  to:  www.aci-int.org 
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Life-Cycle  Computer-Aided  Data  Project 

Ken  Humphreys 

Pacific  Northwest  Laboratories 

Construction  industry  customers  demand  products  that  are  functional,  energy  efficient, 
and  environmentally  responsible.  With  increased  regulation  and  international 
environmental  standards,  the  application  and  performance  of  products  are  changing  and 
wider  global  markets  are  developing.  The  life-cycle  assessment  approach  (LCA)  relates 
to  U.S.  industry  competitiveness  and  is  a topic  of  the  International  Standards 
Organization  (ISO).  This  directly  affects  business  decision  making  and  product  design. 

This  project  is  designed  to  address  two  difficulties  associated  with  integrating  LCA  into 
business  practice;  lack  of  standardized  LCA  tools  and  lack  of  standardized  data  sets.  The 
lack  of  tools  and  data  makes  widespread,  consistent,  and  cost-effective  use  of  LCA 
virtually  impossible.  The  project’s  overall  objective  is  to  develop  tools  and  data  that  will 
facilitate  the  use  of  LCA  within  industry  and  government  as  part  of  routine  business 
decision  making.  Specific  goals  are: 

□ To  develop  and  deploy  to  industry  and  government  a computer  modeling  system  that 
supports  management,  control,  and  manipulation  of  life-cycle  data. 

□ To  collect  and  disseminate  energy  and  environmental  data  for  industrial  commodities 
(such  as  primary  metals,  bulk  chemicals,  forest  products,  plastics,  glass,  and  cement) 
to  support  the  conduct  of  LC As. 

Industry  is  participating  in  the  project  through  in-kind  financial  participation  through  data 
collection,  analysis,  and  review  and  through  a formal  advisory  group  that  provides 
guidance  to  the  data  development  effort  and  helps  define  the  software  system 
requirements  from  an  industrial  user’s  perspective. 

The  concept  for  the  software  modeling  was  completed  in  1995  and  major  data  efforts  are 
underway.  A production  version  of  the  LCA  inventory  module  was  due  to  be  released  in 
1996. 
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Software  Agents  for  Knowledge  Sharing 
Timothy  Finin 

University  of  Maryland,  Baltimore  County 


1.  Background 

This  presentation  involved  a description,  roles,  and  architectures  of  a software  agent.  In 
addition,  an  overview  of  agent  programming  languages  was  presented.  The  second  part 
of  the  presentation  involved  agent  communication  and  knowledge  sharing  technology. 
This  technology  is  critical  for  the  future  of  any  CIKS  system  as  it  relates  to  the  automated 
exchange  of  knowledge  bases  in  an  environment  such  as  the  Internet.  Realizing  the  need 
to  interface  knowledge  in  a heterogeneous  computing  environment,  the  design  of 
knowledge  bases  normally  performed  independently  must  be  done  with  some  degree  of 
consistency  or  compatibility,  thus  producing  seamless  integration  from  a user’s 
perspective. 

2.  Software  Agents 

Software  agents  are  represented  by  the  following  entities: 

□ Daemons  (e.g.,  ftp  agent) 

□ User  interface  clients  (e.g.,  email  agent) 

□ Physical  agents  (e.g.,  robotics) 

□ Believable  agents  (e.g.,  virtual  reality  and  graphics) 

□ Intelligent  software  agents 

Several  knowledge  categories  can  be  associated  with  agents.  These  include  intelligent 
human-computer  interface  agents  and  adaptive  user  modeling  agents,  personal  knowledge 
retrieval  agents,  mobile  software  technologies,  and  cooperative  software  agents  (e.g., 
resource  discovery,  mediators  and  facilitators,  and  market  agents).  An  emerging  system- 
building paradigm  has  developed  involving  agent  technology.  This  paradigm  is 
characterized  by  distributed  systems,  mobile  code,  artificial  intelligence  (cognitive 
science),  machine  learning,  and  database  and  knowledge  base  technologies.  This 
paradigm  is  important  in  that  it  addresses  current  knowledge  issues  which  tend  to  be  fully 
distributed  and  heterogeneous  and  the  technologies  are  scalable.  Key  concepts  important 
to  the  definition  of  a software  agent  are  represented  by  goal-directed  processes,  their 
awareness  and  reaction  to  a given  environment,  and  their  interaction  and  cooperation 
with  other  agents  (mobility). 
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2.1  Agent  Architectures  and  Programming  Technology 

Several  architectures  are  being  used  by  agent  developers.  These  extend  beyond  the 
client-server  architecture  models,  are  mediated  architectures,  represent  single  agents  and 
are  multi-agent  systems.  Agent  cooperation  requires  a communication  environment  and 
uses  an  Agent  Communication  Language  (ACL).  CORBA,  KQML,  and  KJF  are 
representative  of  ACLs. 

Agents  can  be  developed  using  many  different  programming  languages  which  have  the 
following  set  of  characteristics: 

□ Multi-threaded  capabilities 

□ Communication  and  security  support 

□ Mobility 

□ Graphical  user  interface  support 

□ Interoperability  features  that  support  mediated  features  and  component-based 
programming. 


Software  agents  offer  an  opportunity  to  develop  very  large-scale  distributed 
heterogeneous  applications  focusing  on  interactions  of  autonomous,  cooperating 
processes  which  can  adapt  to  humans  and  other  agents.  Intelligence  is  always  a desirable 
characteristic. 

The  summary  of  Timothy  Finin’s  presentation  provides  a brief  overview  of  several 
important  aspects  of  software  agents.  Agent  technology  is  a complex  technology  and  a 
detailed  discussion  extends  beyond  the  scope  of  this  report.  However,  the  following 
references  provide  detailed  information  on  agent  technology  and  are  suggested  for  further 
reading. 
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3.  Working  Group  Reports 

CIKS  working  groups  met  in  2 breakout  sessions  during  the  workshop.  The  working 
groups  were  charged  with  critiquing  the  proposed  CIKS  framework,  identifying 
opportunities  for  partnerships,  identifying  user  needs,  and  developing  and  prioritizing 
recommendations  for  the  NIST  role.  Groups  that  met  and  responded  to  the  charge  were; 
Aluminum,  Coatings,  Composites,  and  Concrete.  The  responses  from  the  working 
groups  are  summarized  in  this  chapter.  Formats  vary,  depending  on  the  nature  of  the 
discussions.  For  example,  the  Coating  Working  Group  had  been  meeting  regularly  since 
the  1 996  workshop  and  had  developed  a mature  agenda.  It  was  most  beneficial  for  this 
group  to  direct  their  attention  to  furthering  ongoing  activities  and  report  the  status  of  their 
work  and  plans  for  furthering  their  partnerships  and  projects.  The  Concrete  Working 
Group  had  a good  representation  and  through  projects  identified  during  their  sessions, 
developed  valuable  information  for  future  work  and  strong  partnerships  and  actions 
directed  to  synergistic  goals. 

3.1  Aluminum 

Chair:  Randy  Kissell,  TGB  Group 

3.1.1  Summary  of  Discussion 


This  group’s  discussion  focused  on  interactions  between  NIST  and  The  Aluminum 
Association.  The  Aluminum  Association’s  Engineering  and  Design  Task  Force  has 
developed  an  Aluminum  Design  Manual.  Primarily  building  designers  who  require 
design  information  on  aluminum  material  properties  and  products  use  the  manual.  The 
group  recommended  the  CIKS  framework  as  a method  for  disseminating  the  contents  of 
the  manual.  Initially,  it  was  thought  that  product  data  could  be  included  as  a component 
of  CIKS.  However,  the  CIKS  concept  does  not  incorporate  the  resources  or  capabilities 
for  creating  an  operational  repository  for  data  storage  and  access.  Therefore,  this  project 
is  not  feasible  for  CIKS-residency.  Rather,  NIST  facilities  (e.g.,  the  CIKS  testbed)  could 
be  made  available  to  assist  aluminum  industry  organizations  in  the  implementation  of 
databases. 

3.1.2  Current  Working  Group  Project  Status 

Subsequent  meetings  were  held  with  the  Aluminum  Association  Staff  and  the 
Engineering  and  Design  Task  Force.  The  current  activity  involves  a linkage  between  the 
CIKS  website  and  the  Aluminum  Association  website.  It  is  expected  that,  through  this 
linkage,  some  of  the  needs  of  building  designers  and  other  knowledge  users  will  be 
served. 
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3.2  Coatings 

Chair:  Bernard  Appleman,  The  Society  for  Protective  Coatings 

3.2.1  Preliminary 

The  Chairman  reviewed  the  objectives  of  the  meeting.  This  group  had  met  several  times 
and  had  previously  established  priorities.  These  priorities  are  documented  in  NISTIR 
6003  [1].  Therefore,  the  focus  of  the  present  meeting  was  to  review7  on-going  programs, 
and  identify  needs  for  additional  or  expanded  efforts.  Representatives  were  present  from 
the  Coatings  and  Information  Technology  Working  Groups. 

3.2.2  Current  Activities 

The  following  on-going  Coatings  Working  Group  activities  were  discussed.  Overviews 
of  the  projects  were  presented  in  addition  to  their  status  and  expected  results. 

3.2.2. 1 Technical  Data  Sheet  Format 

This  activity  was  initiated  by  the  working  group  in  June  of  1 996,  an  activity  chaired  by 
Robert  Kogler  of  the  Federal  Highway  Administration.  The  proposed  guide  was  then 
submitted  to  the  SSPC,  C.4.10  Committee  on  Knowledge  Based  Systems  for  Coatings, 
for  discussion  and  balloting.  The  guide  was  published  in  August  1999  by  SSPC  as  Guide 
13.  It  is  currently  being  distributed  in  printed  form  and  is  available  online  through  the 
SSPC  Knowledge  Center  at  its  website  ( www.sspc.org). 

The  new  guide  will  promote  consistency  and  improve  the  reporting  of  coating  product 
data  among  coating  manufacturers/suppliers  and  users.  It  is  especially  useful  when 
computerized  databases  are  developed  and  they  aid  in  the  search  and  retrieval  of  product 
data.  The  guide  will  also  be  used  in  printed  form  by  coating  manufacturers  and  suppliers 
in  communicating  information  on  printed  technical  data  sheets. 

Future  work  related  to  this  project  will  be  to  develop  a template  for  coating 
manufacturers  to  “fill-in”  fields  for  product  data  sheets,  and  communicate  this  to  a 
database  maintained  as  a central  location  or  at  the  manufacturers  facility.  Primary  users 
of  the  guide  are  expected  to  include  transportation  agencies  involved  with  maintaining 
performance  data  related  to  conformance  testing  of  bridge  coatings,  and  marine  coatings 
users. 

3.2.2.2  Internet  Users  Guide 

Recognizing  the  need  to  provide  assistance  to  new  users  of  the  Internet,  the  working 
group,  in  collaboration  with  the  SSPC  C.4.10  Committee,  developed  an  Internet  Users 
Guide.  This  guide  has  been  converted  to  copyrighted  SSPC  tutorials  that  were  given 
during  the  1997  and  1998  SSPC  Conventions.  At  each  convention,  an  introductory  and 
intermediate  tutorial  was  given.  Response  for  the  tutorials  was  positive  and  generally 
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well  accepted.  This  was  an  important  step  in  bringing  coating  industry  users  up  to  speed 
on  Internet  technologies  such  as  getting  connected,  website  navigation  and  authoring, 
familiarity  with  the  SSPC  website  and  electronic  commerce. 

3. 2.2.3  Expert  Systems  State-of-the-art  Report 

The  SSPC  C.4.10  Committee  is  conducting  this  project.  It  is  in  progress. 

3. 2.2.4  CIKS/SSPC  Activities  at  SSPC  Conferences 

In  additional  to  preparing  the  tutorials  described  in  Section  3.2.2,  the  CIKS  Coatings 
Working  Group  and  SSPC  Committee  C.4.10  have  worked  together  on  several  project 
and  held  several  joint  meetings: 

□ An  SSPC  ’96  Technical  Seminar  [4]  on  “Doing  Business  On-Line:  Internet 
Applications  and  Resources”  was  held  in  1 996.  The  seminar  was  intended  to  provide 
coating  industry  representatives  with  information  on  accessing  and  using  the  Internet 
from  a user  and  business  perspective.  Talks  in  the  seminar  included: 

■ “Coating  Industry  Knowledge  Base  Systems:  An  Introduction  to  the  SSPC 
Knowledge  Center  and  the  NIST  Computer-Integrated  Knowledge  Systems 
Network”  by  Simon  K.  Boocock,  SSPC,  and  Lawrence  Kaetzel,  NIST 

■ “Internet  How  To’s”  by  Michael  F.  MeLampy,  KTA-Tator,  Inc. 

■ “Does  the  Internet  Belong  in  Your  Business  Future?”  by  Renee  E.  McHenry, 
Northwestern  University,  Infrastructure  Technology  Institute 

■ “SSPC  On-Line:  Electronic  Communication  and  the  SSPC  Member”  by  Simon  K. 
Boocock,  SSPC 

■ “A  Brief  Guide  to  Internet  Resources  for  Coatings-Related  Regulations  and 
Associated  Coating  Information”  by  Mary  E.  McKnight,  NIST 

■ “Electronic  Commerce  and  Intellectual  Property  on  the  Internet:  An  Overview  of 
the  Concepts”  by  Lawrence  Kaetzel  and  Sandra  Padilla,  NIST. 

□ For  fee  SSPC  tutorials  were  developed  by  the  CIKS  Coating  Working  Group 
members  and  presented  during  the  1997  and  1998  SSPC  Conventions.  These 
included: 

■ SSPC  Tutorial  T-45,  “Using  the  Internet  for  Coatings  Business  and  Technology  I” 
presented  by  Renee  McHenry,  Northwestern  University,  Infrastructure 
Technology  Institute 
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■ SSPC  Tutorial  T-49,  “Using  the  Internet  for  Coating  Business  and  Technology  II” 
presented  by  Renee  McHenry,  Northwestern  University,  Infrastructure 
Technology  Institute,  and  Lawrence  Kaetzel  and  Thomas  Kurihara,  NIST 

■ SSPC  Tutorial  T-58,  “Accessing  and  Using  Industrial  Coatings  Information  on 
the  Internet”  by  Lawrence  Kaetzel,  K-Systems  (formerly  of  NIST) 

■ SSPC  Tutorial  T-59,  “Using  the  Internet  as  a Tool  for  Coating  Industry  Business” 
by  Lawrence  Kaetzel,  K-Systems  (formerly  of  NIST) 

3.2.2. 5 Project  to  Improve  Intragroup  Communication 

The  coatings  working  group  has  also  developed  and  published  procedures  for  improving 
the  communication  of  documents.  The  CIKS  testbed  was  utilized  to  install  and  test  a 
mailing  list  server  (LISTSERVER)  and  store  documents  for  review  and  comment.  These 
facilities  resulted  in  the  reduction  in  review  times  for  documents  and  helped  keep 
working  group  members  informed  of  activities  through  electronic  means.  The  project 
was  documented  and  published  as  an  article  titled  “Using  the  Internet  for  Group 
Communication”  in  the  Journal  of  Protective  Coatings  and  Linings  [5].  In  1999,  SSPC 
adopted  this  procedure  in  their  Knowledge  Center  to  improve  the  feedback  and 
information  dissemination  to  their  members. 

3. 2.2. 6 SSPC  Knowledge  Center  on  Coatings 

Chairman  Appleman  briefly  described  the  concept  and  plans  for  the  SSPC  Knowledge 
Center  which  is  a key  portion  of  SSPC’s  mission.  He  stated  that  CIKS  through  NIST  is  a 
critical  component  of  this  knowledge  center. 

3.2.3  New  Activities 

3.2.3. 1 FHWA/NIST  Coating  Selection  Expert  System 

A joint  project  conducted  by  NIST  and  funded  by  the  Federal  Highway  Administration 
(FHWA)  involves  the  development  of  a bridge  coating  expert  system  (BRCOAT).  The 
system  involves  the  selection  of  coating  materials  for  shop  applied  and  field  applied 
coatings.  It  pertains  to  both  new  bridges  and  maintenance  of  existing  bridges.  The 
intended  user  is  a civil  engineer  who  has  little  or  no  knowledge  on  coatings.  Decisions 
are  currently  made  based  on  expert  opinion  and  FHWA  research  on  coatings.  Currently, 
the  system  is  in  its  second  version  and  will  be  placed  in  use  at  one  of  the  FHWA  districts 
for  further  testing  and  implementation.  The  system  was  described  in  the  paper  “A 
Systematic  Approach  to  Coating  System  Selection  for  Highway  Bridges  Using  the 
BRCOAT  Knowledge  Based  System”  [6].  Further  work  on  the  system  is  expected  to 
involve  the  addition  of  product  and  research  data  on  coating  performance  and 
accessibility  through  a website. 

3.2. 3.2  Infrastructure  Technology  Institute  Coating  Maintenance  Expert  System 
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This  system  is  being  developed  to  assist  state  engineers  in  the  decision  process.  It 
includes  pre-  and  post-inspection  of  the  bridge  surface.  The  decision  is  based  on 
condition  assessment  and  includes  economic  analysis  of  alternatives.  The  working  model 
was  expected  to  be  presented  in  the  Spring  of  1998. 

3. 2. 3. 3 Partnership  on  Coatings  for  Highway  Structures 

From  the  above  project  descriptions,  it  is  evident  that  there  are  several  different  groups 
working  on  developing  knowledge  sources  and  databases  for  highway  bridges.  There  is 
interest  among  four  key  groups  from  NIST,  FHWA,  ITI,  and  SSPC  to  coordinate  these 
activities  and  to  provide  tools  for  the  bridge  agencies  and  others  in  need  of  this 
knowledge.  One  goal  is  to  establish  procedures  for  mapping  different  data  forms  and 
accounting  for  their  different  structures  and  levels  of  granularity.  It  is  noted  that  it  is 
important  to  have  common  definitions  (e.g.,  the  term  “thermal  coatings”  had  different 
meanings  to  different  individuals  in  the  group).  The  question  of  copyright  arose  because 
some  organizations  generate  substantial  revenue  from  selling  their  copyrighted  glossaries 
or  dictionaries.  The  framework  for  the  partnership  is  shown  in  Figure  3.1. 
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Figure  3.1:  Coating  Partnership  for  Highway  Structures. 

3.2.4.4  Survey  on  Needs  for  Coating  Knowledge 

This  was  an  area  that  was  suggested  by  the  organizers  of  the  CIKS  workshop.  The  SSPC 
Strategic  Planning  Committee  had  conducted  several  surveys  in  1 996  on  this  need  in  the 
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area  of  coatings  knowledge.  SSPC  will  provide  summaries  of  those  surveys  to  the 
working  group.  On  the  basis  of  this  information,  additional  surveys  could  be  developed 
and  discussed  during  SSPC/CIKS  Group  meeting  at  the  SSPC  ’97  Convention  in  San 
Diego. 

3.2.5  Partnerships 

A discussion  was  held  on  the  need  to  work  with  other  organizations  that  have  a need  or 
have  an  interest  in  protective  coatings.  This  would  result  in  broadening  the  scope  of 
CIKS/SSPC  Working  Group.  This  would  encourage  access  to  other  construction  industry 
databases.  Examples  of  other  organizations  and  databases  are  as  follows: 

□ National  Bridge  Inventory, 

□ The  MasterSpec  database  of  the  Construction  Specification  Institute  and  the 
American  Institute  of  Architects, 

□ Materials  Testing  Institute  (MTI), 

□ American  Association  of  State  Highway  and  Transportation  Officials  (AASHTO), 

□ Individual  engineering  firms. 

It  was  noted  that  some  organizations  (e.g.,  Amoco)  have  large  in-house  databases,  but 
these  are  very  expensive  to  maintain.  Organizations  would  benefit  by  having  access  to  an 
accurate,  comprehensive,  up-to-date,  and  easily  accessed  industry  wide  database.  One 
approach  is  for  SSPC  to  develop  a multi-use  web  base  database  format.  An  example  of 
an  existing  form  would  be  from  the  material  safety  data  sheet  database  that  has  been 
established.  It  is  not  known  how  often  these  are  updated  or  the  degree  of  validity. 


3.3  Composites  and  Geosynthetics 

Chair:  Douglas  Bamo,  Market  Development  Alliance 

The  Composites  and  Geosynthetics  Working  Groups  met  jointly  during  the  breakout 
sessions.  Discussion  during  their  sessions  followed  closely  the  charge  to  working  groups. 
This  is  largely  due  to  the  fact  that  the  composites  working  group  had  not  met  since  the 
1 996  workshop  and  the  Geosynthetics  working  group  was  newly  formed. 

3.3.1  Summary  of  discussions 

The  group  had  some  difficulty  characterizing  the  CIKS  concept.  However,  user  needs,  a 
conceptual  approach  and  a critique  of  CIKS  was  discussed  and  reported.  The  group 
summarized  user  needs  as  follows: 
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Short-term  computer  based  needs  (3-6  months) 

□ FAQ’s  (frequently  asked  questions) 

□ Bulletin  board 

□ List  of  experts  and  resources 

□ List  of  applicable  software  & hardware 

□ CIKS  strawman 

□ Guidance/  interactive  versus  static. 

The  desired  CIKS  system  for  composites/geosynthetics  was  further  characterized  as 
follows: 

□ Interactive 

□ User  friendly 

□ Quality  assurance 

□ Compatible 

□ Organizational  stamp  (validity  & accuracy) 

□ Time  sensitive  (just  in  time  delivery) 

□ Provide  both  free  information  and  electronic  commerce 

A developmental  approach  for  the  CIKS  system  that  would  apply  to  the  working  group’s 
needs  would  take  the  following  form: 
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Phase 


% cost 


Organization(s) 


Strawman 

Define  CIKS  (features, 
benefits) 

10 

NIST/constraction 

industry/CONMAT(CERF) 

DEMO 

60 

NIST  (server  ACI,  SSPC) 

(working  site  that  acts  out 
the  strawman) 

BETA 

30 

NIST/Commercial  entity 

Commercialization 

NIST/CONMAT  (CERF)/ 

Not-for-profit/MEP 

3.3.2  Critique  of  the  CIKS  System 

The  group  discussions  resulted  in  the  following  statements  and  assumptions  for  a CIKS 
system  for  composites/geosynthetics  industries. 

□ End-user  (ultimate  customer)  is  under-represented 

□ The  assumption  that  associations  represent  their  industry(s)  varies  by 
organization.  Need  process  to  validate  (peer  review  or  refereed  protocol). 

□ Impedence  mismatch  between  information  and  construction  industry 
communities 

□ CIKS  needs  a permanent  ownership  (sustained  commitment  and  capability) 

□ Participants  role  is  directly  proportional  to  the  size  and  fragmentation  of  the 
industry  segment 

□ Information  technology  potential  to  filter  or  modify  data 

□ Derived  benefits  are  represented  in  the  information  infrastructure 

□ CIKS  development  is  an  evolutionary  process: 

□ Staged  capabilities 
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□ Match  application  of  information  technology  to  market 


3.3.3  Conclusions  and  Recommendations 

□ CIKS  is  clearly  a capability  that  can  benefit  an  emerging  material  technology  like 
fiber  reinforced  composites  even  more  than  traditional  materials. 

□ The  Market  Development  Alliance  (MDA)  should  stay  active  in  the  development  and 
monitoring  of  CIKS 

□ Dr.  Bernard  Appleman  should  be  invited  to  speak  to  either  the  MDA  or  STEERCOM 
at  an  upcoming  meeting  in  order  to  bring  their  success  story  to  our  attention.  It  is  a 
model  that  MDA  can  use  to  great  effect. 
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3.4  Concrete  and  Masonry 

Chair:  David  Fowler,  University  of  Texas  at  Austin 

The  Concrete  and  Masonry  Working  Group  was  represented  primarily  by  members  of  the 
concrete  industry.  This  group  followed  the  working  charge  closely  which  resulted  in  a 
structured  discussion  and  presentation  of  prioritized  pilot  projects  and  workflow 
recommendations.  Results  of  the  group  were  very  synergistic,  suggestion  that  strong 
partnerships  could  be  formed  among  the  representative  organizations  and  NIST.  The 
following  represents  a summary  of  the  projects  identified  and  presented  by  the  group. 

Priority  #1:  Develop  a Highway  Materials  Database 

Duration:  1 year  to  4 years 

Starting  date:  1 September  1997 

Sponsor:  TxDOT/FHWA 

Research  Agency:  Center  for  Transportation  Research/University  of  Texas  at  Austin 
NIST  Role:  Consultant 

Priority  #2:  Extend  Concrete  Repair  (CONREP)  Expert  System 
Duration:  4 years 
Start  date:  1994 

Sponsor:  Waterways  Experiment  Station/NIST 
Research  Agency:  NIST 
NIST  Role:  Research/Funding 

Priority  #3 : Develop  Masonry  Materials  Database  for  the  World  Wide  Web 
Duration:  1 year  to  2 years 
Start  Date:  Tentatively  Fall  1998 

Sponsor:  American  Concrete  Institute  Committee  531/Council  for  Masonry  Research 
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Seed  Funding:  Concrete  Research  Council,  Council  for  Masonry  Research 
Primary  Funding:  National  Science  Foundation,  HUD  (PATH  Program),  NIST 
NIST  Role:  Consultant,  possible  funding 
Priority  #4:  Concrete  and  Masonry  User  Model 

Features:  Computer  based  training,  decision  support  system  for  users  based  on  capturing 
information  streams  from  existing  sources  including  performance  histories  of  facilities. 

Users  of  the  system  would  provide  feedback  to  new  construction  process  for  increased 
quality  and  performance  and  for  improving  repair/rehabilitation  process. 

Decision  Support  System  for  the  Repair  and  Rehabilitation  of  Structures 

Peter  Emmons,  Structural  Preservation  Systems  presented  a model  which  represents  a 
computer  based  system  he  is  developing.  The  model  includes  computer  based  training 
and  decision  support  capabilities  and  multimedia  knowledge  formats.  Figure  3.2  shows  a 
diagram  of  the  system.  This  model  is  complimentary  to  the  CIKS  concept  on  a somewhat 
smaller  scale. 


CIKS  Concrete  & Masonry  Working  Group 


Knowledge  System  Model 
User  perspective 


DSS  Decision 


CBT  Training 


Design 

Construct,  Repair 


r 


* 

Existing  structure 


New  structure 


if 

Researcher/students/contractors/engineers/suppliers/owners 


Peter  Emmons 


Figure  3.2:  Diagram  of  a decision  support  system. 
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3.4.1  CIKS  Concrete  Working  Group  Status  and  Activities 

Since  the  1997  workshop,  the  Concrete  Working  Group  has  met  during  the  Spring  and 
Fall  Conventions  of  the  American  Concrete  Institute  (ACI).  During  the  Spring  1999 
meeting  the  working  group  merged  with  the  ACI  Committee  235  on  “Knowledge  Based 
Systems  and  Mathematical  Modeling  for  Materials.”  A new  subcommittee  235-A  on 
“Knowledge  Interoperability”  was  formed  and  it  is  anticipated  that  the  working  groups 
members  will  be  active  members  of  the  ACI  subcommittee.  This  process  follows  closely 
the  role  assumed  by  the  CIKS  Coatings  Working  Group.  Like  the  Coatings  Working 
Group  the  Concrete  Working  Group  has  developed  similar  strategies  for  partnerships. 
Priorities  1 and  2 described  above  are  currently  being  implemented  by  NIST,  Waterways 
Experiment  Station,  and  the  University  of  Texas  at  Austin.  ACI  Committee  235  has 
developed  a journal  article  to  be  published  in  the  December  1999  edition  of  Concrete 
International  that  describes  the  partnership  and  the  role  of  Committee  235  in  addressing 
the  knowledge  needs  of  the  concrete  industry.  Technical  Sessions  are  being  conducted 
during  the  ACI  Fall  1999  Convention  in  Baltimore  and,  pending  final  approval  and 
review,  the  proceedings  will  be  published  as  an  ACI  Special  Publication. 
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4.  Workshop  Conclusions  and  Recommendations 

The  2nd  CIKS  Workshop  was  a success  from  several  prospectives,  but  not  all. 

Information  gained  from  the  wrapup  sessions  and  working  group  recommendations 
provided  realistic  projections  on  the  direction  and  magnitude  of  the  vast  amount  of  work 
and  collaboration  required  to  make  CIKS  a successful  knowledge  based  network  for  the 
construction  industry.  The  primary  points  covered  in  the  wrapup  discussions  and  the 
consensus  of  the  attendees  are  listed  below. 

4.1  Conclusions 

Workshop  attendance  - Participants  in  the  workshop  were  mainly  representatives  of 
facility  owners,  researchers,  managers,  and  information  technologists.  A significant  base 
of  knowledge  users  was  lacking. 

Keynote  presentations  - Part  I of  the  keynotes  described  important  methods  and 
information  tools  that  are  necessary  for  a distributed  and  heterogeneous  CIKS  system. 
The  presentation  on  terminology  raised  awareness  of  the  importance  of  this  topic  for 
knowledge  sharing.  Information  sharing  is  complex  and  futuristic  topic,  but  one  that 
must  be  addressed  in  the  CIKS  environment.  Actual  demonstrations  of  prototype 
systems  are  essential  to  convey  the  information  that  can  be  digested  and  used  by 
construction  industry  segments. 

Part  II  of  the  keynotes  involved  discussions  of  actual  applications  for  construction 
industry  use.  These  presentations  presented  information  that  can  be  used  by  the 
workshop  participants. 

Critique  of  the  CIKS  framework  - The  vast  scope  of  CIKS  and  its  objectives  made  it 
difficult  for  some  of  the  participants  to  relate  to  their  particular  needs.  This  demonstrates 
the  need  for  partnership  among  organizations  that  are  actively  pursuing  solutions  to 
knowledge  user  needs  and  the  need  to  team  with  information  technologists  to  “interpret” 
information  technology  methodologies.  The  need  for  a strawman  was  obvious  and  the 
Coatings  Working  Group  activities  showed  how  one  segment  of  the  construction 
materials  area  is  addressing  key  issues  for  knowledge  use.  Also,  greater  emphasis  should 
be  placed  on  the  CIKS  testbed  to  assist  industry  segments  in  testing  and  building 
prototype  systems. 

Working  group  results  - Two  of  the  working  groups;  coatings  and  concrete  made 
significant  progress  during  their  breakout  sessions:  coatings  in  the  area  of  addressing 
future  work  for  developing  decision  support  systems  and  creating  partnerships  and 
concrete,  in  the  area  of  partnerships  and  the  development  of  an  agenda  for  sharing 
information  and  methodologies  for  pavement  management  systems  and  hydraulic 
structures. 
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The  joint  Composites  and  Geosynthetic  Materials  Group  developed  useful  information 
that  is  necessary  for  defining  their  user  needs  and  characterizing  the  CIKS  system. 

It  was  apparent  that  the  assistance  provided  by  members  of  the  Information  Technology 
Group  during  the  working  group  sessions  helped  to  explain  the  details  of  specific 
information  tools  for  the  materials  specialists. 

Expectations  for  future  workshops  - Perhaps  the  strongest  justification  for  future 
workshops  is  the  need  to  demonstrate  applications  and  technologies  to  system  developers, 
users,  and  mangers.  These  demonstrations  would  include  organizations  actively  engaged 
in  developing  knowledge  bases  and  who  have  legacy  systems  and  those  who  are  just 
beginning.  Using  a strawman  and  model  systems  should  be  considered  as  a core  for 
future  meetings.  A major  focus  should  be  in  the  areas  of  coatings  and  concrete  materials. 

4.2  Recommendations 

The  main  recommendations  from  the  workshop  concerned  the  CIKS  frame  work  and 
future  workshops.  They  are: 

□ A strawman  should  be  developed  based  on  the  coatings  and  concrete  working  group 
activities.  This  strawman  should  have  priority  in  the  next  phase  in  the  CIKS 
development  and  should  be  presented  at  a future  CIKS  workshop. 

□ A future  CIKS  workshop  should  include  greater  representation  from  the  construction 
industry  user  community. 

□ Working  groups  should  continue  to  meet  at  6 month  intervals  in  order  to  maintain 
progress  in  their  respective  areas. 

□ The  report  from  the  workshop  should  be  distributed  to  attendees  and  construction 
industry  organizations  interested  in  knowledge  base  activities. 

□ Industry  should  express  its  support  to  NIST  for  CIKS 
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APPENDIX  A:  WORKSHOP  PROGRAM 


Program 

2nd  Annual  CIKS  Workshop 


September  24, 1997 

8:00-8:30  Registration 

8:30-8:40  Welcome  and  Introduction 

8:40-9:00  Sound  Decisions  in  Design, 

Construction  and  Use  of 
Construction  Facilities 


Lawrence  Kaetzel  (Workshop  Chair) 


Richard  Wright,  Director 
NIST,  Building  and  Fire 
Research  Laboratory 


Keynote  Presentations  I:  Building  Blocks  for  Knowledge  Exchange 


9:00-10:30  The  DARPA  Approach  to  Knowledge 
Sharing 


David  Gunning,  Program 
Manager,  (DARPA)  Defense 
Advanced  Research  Projects 
Agency 


Terminology:  Need  for  Consistency  and  Sue  Ellen  Wright,  Kent  State 
Current  Efforts  to  Standardize  University 


Tools  for  Knowledge  Sharing 


Timothy  Finin,  University  of 
Maryland  Baltimore  Campus 


Electronic  Commerce  for  the  Engineering  James  Andrew  Arnold 
Enterprise  Center  for  Integrated  Facility 

Information,  Stanford 
University 


10:30-10:45  Break 


Keynote  Presentations  II:  Knowledge  Exchange  Efforts  and  the  CIKS 

Framework 

10:45-12:15  Society  for  Protective  Coatings  (SSPC)  Dr.  Bernard  Appleman, 

Coating  Knowledge  Center  Executive  Director,  Society 

For  Protective  Coatings 


10:45-12:15  Construction  Supemetwork 


Alan  Sparkman,  Publisher 
Aberdeen  Group,  Electronic 
Media  Division 
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Life-Cycle  Computer-Aided  Data  Project 

Ken  Humphreys 

Pacific  Northwest  Laboratory 

CIKS  Framework  and  Testbed 

Tom  Kurihara,  Computer 
Specialist,  NIST,  Building 
and  Fire  Research 

12:15-12:45 

Panel  Discussion 

12:45-1:00 

Charge  to  Material  Working  Groups 

J.  Meyer  (Workshop 
Co-Chair),  Director, 

Research  and  International 
Programs,  CERF 

1:00-2:00 

Lunch 

2:00-5:00 

Material  Working  Groups:  Session  I 

Goal  1 : Identify  user  needs 

Goal  2:  Critique  CIKS  Framework 

5:00-5:15 

Break 

5:15-5:45 

Summary  of  Working  Group  Sessions 
(Working  Group  Chairs) 

6:30 

Cocktails  (cash  bar) 

7:00 

Dinner 

John  Rumble,  Chief 

NIST,  Office  of  Standard 
Reference  Data 

September  25, 

1997 

8:30-9:00 

Plenary  Session 

Preliminary  reports  from  material  working  groups 

9:00-12:30 

Material  Working  Groups:  Session  II 

Goal  1 : Opportunity  assessment,  develop  recommendations 

Goal  2:  Develop  working  group  reports 

Information  Technology  Working  Group:  Session  I 

12:30-1:30 

Lunch 

1:30-2:30 

Summary,  wrapup  and  next  steps 

2:30-5:00 

Tour  and  demonstrations  of  NIST/CIKS  test  bed 

5:00  ADJOURN 
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APPENDIX  B:  SPONSORING  ORGANIZATIONS,  STEERING  AND 
ORGANIZING  COMMITTEE  MEMBERS 

Sponsoring  Organizations 

□ Civil  Engineering  Research  Foundation  (CERF) 

□ Construction  Materials  Council  (CONMAT),  CERF 

□ American  Society  for  Testing  and  Materials  (ASTM) 


Steering  Committee 
John  D.  Meyer,  Chair,  CERF 

Bernard  Appleman,  The  Society  for  Protective  Coatings 

Douglas  Bamo,  SPI  Composites  Institute 

Timothy  Finin,  University  of  Maryland,  Baltimore  County 

David  Fowler,  University  of  Texas  at  Austin 

Geoffrey  Frohnsdorff,  NIST/BFRL 

David  Jefferson,  Consultant 

Larry  Kaetzel,  NIST/BFRL 

Gil  Kaufman,  The  Aluminum  Association 

Organizing  Committee 

Larry  Kaetzel,  Chair,  NIST/BFRL 

Richard  Belle,  CERF 

James  Clifton,  NIST/BFRL 

Dave  Evans,  NIST/BFRL 

Janice  Hagood,  NIST/BFRL 

Randolph  Kissell,  TGB  Partnership 

Robert  Koemer,  Geosynthetics  Institute 

Robert  Kogler,  Federal  Highway  Administration 

Tom  Kurihara,  NIST/BFRL 

Charles  Sturrock,  NIST/MATLS 

Nancy  Wilkin,  NIST/BFRL 

Mike  Zupanick,  Consultant 
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APPENDIX  C:  LISTING  OF  WORKSHOP  PARTICIPANTS 


Bernard  Appleman 
The  Society  for  Protective  Coatings 
40  24th  St.,  6th  Floor 
Pittsburgh,  PA  1 5222-4643 

James  Andrew  Arnold 
Stanford  University 
Bldg  550,  Rm.  553 
Stanford,  CA  94305 


Douglas  Bamo 
Composites  Institute 
2635  Old  Columbus  Rd. 

Granville,  OH  43023 

Joannie  Chin 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 
Gaithersburg,  20899 

James  Clifton 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 
Gaithersburg,  MD  20899 

Peter  Emmons 

Structural  Preservation  Systems 
3761  Commerce  Drive 
Baltimore,  MD  21227 

David  Evans 

NIST,  Building  and  Fire  Research  Lab 
Building  224,  B250 
Gaithersburg,  MD  20899 

Grace  Hsuan 
GRi/Drexel  University 
33  Lancaster  Ave. 

Philadelphia,  PA  19104 


Clarissa  Ferraris 

NIST,  Building  and  Fire  Research  Lab 
Building  226,  B350 
Gaithersburg,  MD  20899 

Timothy  Finin 

University  of  Maryland,  Baltimore  County 
Dept  of  Computer  Science  and  Electrical 
Engineering 
Baltimore,  MD  21250 

Russ  Fleming 
National  Fire  Sprinkler 


David  Fowler 

University  of  Texas  at  Austin 
Center  for  Aggregates  Research 
Austin,  TX  78712 

Michael  Galier 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 
Gaithersburg,  MD  20899 

Pravin  Gandhi 
Underwriters  Laboratory 
333  Pfingsten  Rd. 

Northbrook,  IL  60062 

Jeffrey  Greenwald 

National  Concrete  Masonry  Association 


Janice  Hagood 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 
Gaithersburg,  MD  20899 
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Kenneth  Humphreys 

Pacific  Northwest  Laboratories 

P.O.  Box  999 

Richland,  WA  99352 

Robert  Kogler 

FHWA,  Turner  Fairbank  Highway 
Research  Center 

6300  Old  Georgetown  Pike 

McLean,  V A 22101 

Kristin  Iden 

FHWA,  Turner  Fairbank  Highway 
Research  Center 

6300  Georgetown  Pike 

McLean,  V A 22101 

Tom  Kurihara 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 

Gaithersburg,  MD  20899 

Nora  Jason 

NIST,  Building  and  Fire  Research  Lab 
Bldg  224,  A252 

Gaithersburg,  MD  20899 

Yannis  Labrou 

University  of  Maryland,  Baltimore  County 
Dept  of  Computer  Science  and  Electrical 
Engineering 

Baltimore,  MD  2 1 250 

David  Jefferson 

8121  Langport  Terrace 

Gaithersburg,  MD  20877 

Kenneth  Litkowski 

CL  Research 

20239  Lea  Pond  Place 

Gaithersburg,  MD  20879 

Lawrence  Kaetzel 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 

Gaithersburg,  MD  20899 

Colin  Lobo 

NRMCA 

900  Spring  St. 

Silver  Spring,  MD  20910 

Randy  Kissell 

TGB 

1325  Farmview  rd. 

Hillsborough,  NC  27278 

Jonathan  Martin 

NIST 

100  Bureau  Drive,  Stop  8621 

Gaithersburg,  MD  20899 

Robert  Koemer 

Geosynthetic  Institute 

130  Wood  Road 

Springfield,  PA  19064 

James  McDonald 

U.S.  Army  Corps  of  Engineers 

Waterway  Experiment  Station 

3909  Halls  Ferry  Rd. 

Vicksburg,  MS  39180 

John  Meyer 

CERF 

1015  15th  St.,  NW 

Washington,  DC  20005 

Mary  McKnight 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B350 

Gaithersburg,  MD  20899 
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Arantza  Murphy 

CERF 

1015  15th  St.,  NW 

Washington,  DC  20005 

Alan  Sparkman 

The  Aberdeen  Group 
Electronic  Media  Division 

1735  Stadium 

Ann  Arbor,  MI  48 1 03 

James  Pielert 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226 

Gaithersburg,  MD  20899 

Jeff  Stewart 

ITW  Devcon 

353  Meade  Dr. 

Moon  TWP,  PA  15108 

William  Plenge 

American  Concrete  Institute 

P.O.Box  1009 

Pasadena,  MD  21123 

Charles  Sturrock 

NIST/SRD 

Bldg  820,  113 

Gaithersburg,  MD  20899 

Bruce  Rink 

The  Construction  Specification  Institute 
601  Madison  St. 

Alexandria,  V A 22314 

L.  David  Suits 

N.Y.  State  DOT-Geotech 

1220  Washington  Ave. 

Albany,  NY  12232 

John  Rumble 

NIST 

Bldg  820,  113 

Gaithersburg,  MD  20899 

Louis  Sumbry 

Amoco  Corp. 

3700  Bay  Area  Blvd. 

Houston,  TX  77058 

Gajanan  Sadnis 

Howard  University 

404  Northview  Ave. 

Silver  Spring,  MD  20905 

Brian  Trimble 

Brick  Institute  of  America 

1 1490  Commerce  Park 

Reston,  VA  20191 

Diane  Schulman 

The  Aberdeen  Group 

1735  Stadium 

Ann  Arbor,  MI  48 1 03 

Terry  Weigel 

University  of  Louisville 

Dept  of  Civil  Engineering 
Louisville,  KY 

Sue  Ellen  Wright 

Kent  State  University 

Kent,  OH  44242 

Charles  West 

Northwestern  University/Quest 
1801  Maple  Ave. 

Evanston,  IL  60201 
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Richard  Wright 

NIST,  Building  and  Fire  Research  Lab 
Bldg  226,  B216 
Gaithersburg,  MD  20899 

Zhanmin  Zhang 
University  of  Texas  at  Austin 
Center  for  Aggregates  Research 
DCJ  5.200 
Austin,  TX  78712 


APPENDIX  D:  WORKING  GROUP  MEMBERS 


WG1  - Aluminum 


Randy  Kissell,  Chair 
James  Clifton 
Charles  Sturrock 
David  Jefferson 


TGB  Group 
NIST 
NIST 
Consultant 


WG2  - Coatings 


Bernard  Appleman,  Chair 
Michael  Galler 
Gajanan  Sabnis 
Arantza  Murphy 
Sue  Ellen  Wright 
Mary  McKnight 
Ken  Litkowski 
Jeff  Stewart 
Charles  West 
Yannis  Labrou 
Louis  Sumbry 
Robert  Kogler 
Lawrence  Kaetzel 
Charles  Sturrock 


The  Society  for  Protective  Coatings 
NIST 

Howard  University 

Civil  Engineering  Research  Foundation 

Kent  State  University 

NIST 

CL  Research 

ITW  Devcon 

Northwestern  University 

University  of  Maryland,  Baltimore  County 

Amoco 

FHWA 

NIST 

NIST 


WG3  - Composites  & Geosynthetics 
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